[PATCH] D47901: [WIP] [WebAssembly] Update .debug_line section PC addresses during LEB optimization

Sam Clegg via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jun 7 14:59:22 PDT 2018


sbc100 added a comment.

In https://reviews.llvm.org/D47901#1125651, @probinson wrote:

> In https://reviews.llvm.org/D47901#1125643, @sbc100 wrote:
>
> > I there a way we can avoid needing to do this at all?   How about we simply don't allow LEB compression and dwarf in the same output?  It seems OK if building with dwarf in them don't have this optimization.
>
>
> It is not OK for the presence of debug info to affect the construction of the rest of the executable.  Normally this is something only the compiler needs to worry about, but it appears the linker also needs to care.  If I understand the motivation here correctly.


Hmm, I do see your point.  Maybe I can explain in a little more detail:  There is a optional optimization that the wasm lld linker can perform which effectively shrinks the code section by converting padded-LEB128s (used at relocation sites) to non-padded LEB128s.  This only occurs if you pass -O2 to the linker.  We could even make it a separate optional argument.   Obviously when we do this code section compression we change the instruction offsets, which breaks the DWARF information.

So I see a few options here:
(1) Increase the complexity of the linker so it can parse, modify mad re-write the DWARF sections rather than just blindly copying them.
(2) Remove this LEB compression feature from the linker and make it into a separate tool
(3) Make LEB compression and debug sections mutually exclusive.  Would mean that --compress-lebs would automatically imply --strip-debug.

My understanding is that (1) generally goes against the philosophy of linkers in general, but maybe I'm wrong.  If I'm correct then perhaps (2) makes the most sense as it keeps the linker dump and fast.

@probinson After this more detailed explanation are would you still be strongly against (3)?
@ruiu I am right about (1)? i.e. would dwarf parsing and re-writing be outside the normal preview of the linker?


Repository:
  rLLD LLVM Linker

https://reviews.llvm.org/D47901





More information about the llvm-commits mailing list