[PATCH] D59553: [LLD][ELF][DebugInfo] llvm-symbolizer shows incorrect source line info if --gc-sections used

Alexey Lapshin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 8 08:06:57 PDT 2019


avl added a comment.

In D59553#1571425 <https://reviews.llvm.org/D59553#1571425>, @MaskRay wrote:

>




> I agree in this case .text can have 0 link-time address.
> 
> I guess you probably don't need `.dynsym`. If this is a dynamically linked executable, it will have `.interp`, which is usually in the first page. Then `.text` will not have 0 `sh_addr`, and 0 will be an invalid code address. It is not common to have `.dynstr` after `.text` - it is before `.text` in BFD's default linker script.
> 
> For similar reasons, there should not be any .gnu.hash .dynstr `.rodata` `.eh_frame` etc. They are placed before `.text` by default in lld.
> 
> If you have `.note*` sections, you'll probably also place them in the first page. This ensures they are dumped by FreeBSD and Linux kernels when the core file size is limited.
> 
> In summary, to make 0 a valid code address in an lld linked module, lots of assumptions have to be made. These assumptions make the lld patch seem pretty much a hack for a very specialized use case.

Having 0 as a valid code address is quite common for embedded world. 
Please check that article, it describes exactly such a case https://www.embeddedrelated.com/showarticle/900.php
The linker script for that example has

  MEMORY
  {
    flash     (rx)   : ORIGIN = 0, LENGTH = 150K
    ram       (rw!x) : ORIGIN = 0x800000, LENGTH = 32K
  }
  SECTIONS
  {
    .text :
    {
      ./crt0.o(.text*)
      *(.text*)
      *(.strings)
      *(._pm*)
      *(.init)
      *(.fini)
       _etext = . ;
      . = ALIGN(4);
    }  > flash

Other than that there were another mentions of " 0 as a valid code address" in this thread. Sony has such a case. Message from lldb-dev mentioned that: http://lists.llvm.org/pipermail/lldb-dev/2017-March/012091.html .  Having all of that, "0 as a valid code address" does not look like very specialized use case.
It would be useful to support it, especially for embedded applications.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59553/new/

https://reviews.llvm.org/D59553





More information about the llvm-commits mailing list