[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