similar to: [WebAssembly] relocations for dwarf

Sean Silva <chisophugis at gmail.com> writes: > On Mon, Jul 3, 2017 at 11:12 AM, Rafael Avila de Espindola < > rafael.espindola at gmail.com> wrote: > >> Sam Clegg via llvm-dev <llvm-dev at lists.llvm.org> writes: >> >> >> Can you elaborate on semantically what the linker is actually doing for >> >> wasm? >> > >> >

On Mon, Jul 10, 2017 at 4:13 PM, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Sorry for the belated response. I was on vacation last week. A couple of > thoughts on this patch and the story of webassembly linking. And I'm about to be on (mostly) vacation for next 3 weeks :) > > - This patch adds a wasm support as yet another major architecture besides >

Sam Clegg via llvm-dev <llvm-dev at lists.llvm.org> writes: >> Can you elaborate on semantically what the linker is actually doing for >> wasm? > > You are correct that the wasm linker does have more work to do than a > traditional linker. There are more sections that the linker will need > to re-construct fully. This is because there is more high level >

Can you link to docs about the wasm object format? (both relocatable and executable) Also, traditional object file linkers are primarily concerned with concatenating binary blobs with small amount of patching of said binary blobs based on computed virtual (memory) addresses. Or perhaps to put it another way, what traditional object file linkers do is construct program images meant to be mapped

Rafael, here is a repro.tar to look at: https://reviews.llvm.org/F3100177 The attached foo.diff adds a print which shows the issue. ``` NAME: sleep SYMINDEX: 2 NAME: sched_yield SYMINDEX: 1 NAME: __libc_start_main SYMINDEX: 0 ``` `readelf --relocs` Shows that we create : ... 000000255110 002900000007 R_X86_64_JUMP_SLO 0000000000254410 __xstat at GLIBC_2.2.5 + 0 000000255118 001e00000007

Android libc casts its address to the elf header type. So I think start of text? Rafael Avila de Espindola <rafael.espindola at gmail.com> schreef op 30 mei 2017 20:51:19 CEST: >It is missing from lld. > >Do you know what it should point to? The first executable PT_LOAD? > >Thanks, >Rafael > >Carlo Kok via llvm-dev <llvm-dev at lists.llvm.org> writes: >

Hi Sam, First, I want to know the symbol resolution semantics. I can imagine that that is set in stone yet, but just that you guys are still discussing what would be the best semantics or file format for the linkable wasm object file. I think by knowing more about the format and semantics, we can give you guys valuable feedback, as we've been actively working on the linker for a few years

On Jul 27, 2012, at 2:35 AM, Carlo Kok <ck at remobjects.com> wrote: > Hi, > > I had a problem with LLVM not emitting local variable info, even though > I had calls to llvm.dbg.define. After some tracking I found that the > llvm.dbg.declare (and probably value too) have to have a !dbg !nr after > them to get emitted at all. maybe someone can adjust >

Hello, The table generated by lld (Wasm target) have a max size. So this make impossible to add some others functions in the table . As for the moment only one Table is available in WAsm this is the only way to add function in a dynamic way. Having a none static size of the table is useful for a kind dynamic loader/inker at run-time: by adding some exported functions coming from another

Hi Sam, Thanks for your answer! Sorry I didn't really know how to process, but this issue block me to make some legacy C code works without having some glue with a bit static lib ;( (The change have really low risk) The changes I used locally to make dlopen/dlclose et dlsym mechanism works :) : Index: wasm/Writer.cpp =================================================================== ---

Hi llvmers, As you may know, work has been progressing on the experimental WebAssembly backend in llvm. However, there is currently not a good linking story. Most the of existing linking strategies (i.e. those in the emscripten toolchain) involve bitcode linking and whole program compilation at link time. To improve this situation I've been working on adding a wasm backend for lld. My

> On Sep 18, 2017, at 10:13 PM, Carlo Kok <ck at remobjects.com> wrote: > > September 18, 2017 8:17 PM, "Adrian Prantl" <aprantl at apple.com> wrote: > >> Have you tried looking at the --dump-after-all output to see which pass (if any) is adding the >> extra line table entries? >> -- adrian > > > You mean --print-after-all ? I

Hi, When running my own lld generated library/executable I'm getting: LD_LIBRARY_PATH=. ./ConsoleApplication347 ./ConsoleApplication347: symbol lookup error: ./ConsoleApplication347: undefined symbol: (theres nothing after undefined symbol) How can I figure out what's I'm doing wrong? Full log: https://gist.github.com/carlokok/1dd510a16e1922271b520f1c00b14656 readelf -s for

Hi Carlo, Do you have VS2010 handy? It should read the DI fine. Unfortunately, VS2013 is not able to use the debug info we generate. It is on my plans to investigate and fix the generator, but I didn't have enough free cycles recently. -- Tim 2014-09-15 20:30 GMT+04:00 Reid Kleckner <rnk at google.com>: > +Timur > > Hm, this didn't work out of the box for me. > >

if you could simplify it down a bit, that might be helpful - not sure there's a lot to be gained - I imagine it is just a quirk of how we handle these things in the backend to make normal debug info work, but there might be some things to be done to help. On Wed, Dec 21, 2016 at 2:31 PM Carlo Kok <ck at remobjects.com> wrote: >

I think probably the simplest answer is that dbg.declare documents that it must point to an alloca ("This intrinsic provides information about a local element (e.g., variable). The first argument is metadata holding the alloca for the variable. ") - so it's probably best not to think too hard about what it does when that criteria is not met.

Somehow I wish not all parts of a libc but parts that can be provided without a JavaScript wrapper for .wasm can be provided from llvm's libc (leaving a stab implementation for the rest like file system). I've put together a minimal libc on [1] so using a 26kb .wasm binary file one can decode both PNG and JPG using this [2] simple to integrate JavaScript code, can be easily ported in other

It's a wasm testcase that ends up with a 1 mb executable; after 15 minutes I killed it, it doesn't do anything (note that it's waiting on a conditional variable in ALL threads) On Wed, May 8, 2019, at 14:32, Brian Cain wrote: > Are you sure it's not just taking "a long time"? If that build machine doesn't have enormous amounts of memory you could end up with a

Yep, it's once again variable and it's type using different scopes. Is there any strong reason why you set scope for global DIDerivedType? ________________________________________ От: Carlo Kok <ck at remobjects.com> Отправлено: 21 марта 2018 г. 18:22 Кому: Evgeny Leviant; llvm-dev at lists.llvm.org Тема: Re: [llvm-dev] lld/lto/win32 crash on DIE code Thanks! Unfortunately this

r287955 seems like it might be related. -- Sean Silva On Sat, Nov 26, 2016 at 4:06 PM, Sean Silva <chisophugis at gmail.com> wrote: > This sounds buggy to me. What pass is doing this? > > -- Sean Silva > > On Thu, Nov 24, 2016 at 5:39 AM, Carlo Kok via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> I've got some calls like: >>