[PATCH] D49446: [WebAssembly] Move .debug_line section address of dead function outside section range

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jul 25 10:20:46 PDT 2018


dblaikie added a comment.

In https://reviews.llvm.org/D49446#1173389, @yurydelendik wrote:

> In https://reviews.llvm.org/D49446#1172887, @dblaikie wrote:
>
> > Ish - but existing debuggers/linkers already tolerate this sort of debug info - so it'd be ideal/better if WAsm did too. Any address derived from zero would be considered invalid/uninteresting. (similarly for the debug_info itself - you'd find similarly confusing data, where functions start at zero and are X bytes long - so technically a bunch of non-zero bytes are covered by that range, but currently it seems existing debuggers/linkers are OK with this contract too).
>
>
> Currently, the wasm function (dead or alive) never starts from 0. The `Sym->Function->getFunctionCodeOffset()` returns size of the function size field that is placed before function body. If we want debug info to point strict 0, we can change the `DEAD_FUNCTION_OFFSET` to be 0 -- the rest of the patch will stay pretty much the same. I just took one step further and moved that completely on of code range -- with other platforms that's happening automatically since PC is almost never close to 0.
>
> FWIW, the algorithm for the detection of dead function debug entries looks like https://github.com/kripken/emscripten/pull/6884/files#diff-d7e06c82407a72c0476db85b2cf5d3deR157 and requires linker to produce compact LEB values for functions size field length.


Guess there's no chance of reusing the existing ELF logic for this? (I assume the ELF linker and WAsm linker are too different for that)

If it's not going to fall out naturally as a consequence of a single shared implementation, then I'm not too fussed with what value you give dead code - I'd still lean towards zero, but I'll leave it to Rui.


Repository:
  rLLD LLVM Linker

https://reviews.llvm.org/D49446





More information about the llvm-commits mailing list