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

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

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

> In https://reviews.llvm.org/D49446#1167210, @sbc100 wrote:
>
> > I'm still not sure I understand why writing zero here is not a good idea.
>
>
> It will be probably easy to demonstrate on the example. When running the test case (test/wasm/debug-removed-fn.ll) without the patch, the .debug_line data contains the following info
>
>   0x0000000000000005      1      0      1   0             0  is_stmt
>   0x0000000000000008      2      3      1   0             0  is_stmt prologue_end
>   0x0000000000000009      2      3      1   0             0  is_stmt end_sequence
>   0x0000000000000000      5      0      1   0             0  is_stmt
>   0x0000000000000003      6      3      1   0             0  is_stmt prologue_end
>   0x0000000000000004      6      3      1   0             0  is_stmt end_sequence
>
>
> With patch:
>
>   0x0000000000000005      1      0      1   0             0  is_stmt
>   0x0000000000000008      2      3      1   0             0  is_stmt prologue_end
>   0x0000000000000009      2      3      1   0             0  is_stmt end_sequence
>   0x00000000fdead000      5      0      1   0             0  is_stmt
>   0x00000000fdead003      6      3      1   0             0  is_stmt prologue_end
>   0x00000000fdead004      6      3      1   0             0  is_stmt end_sequence
>
>
> Notice that the "bar" function debug data "claims" that the function can be found at addresses 0-4 (without the patch). Then same true for .debug_info.
>
> If the both functions are exported, .debug_line looks like:
>
>   0x0000000000000005      1      0      1   0             0  is_stmt
>   0x0000000000000008      2      3      1   0             0  is_stmt prologue_end
>   0x0000000000000009      2      3      1   0             0  is_stmt end_sequence
>   0x000000000000000a      5      0      1   0             0  is_stmt
>   0x000000000000000d      6      3      1   0             0  is_stmt prologue_end
>   0x000000000000000e      6      3      1   0             0  is_stmt end_sequence
>
>
> Does this explain the problem?


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).


Repository:
  rLLD LLVM Linker

https://reviews.llvm.org/D49446