<div dir="ltr"><div>Thank you for the effort put into this response. It's interesting to see that there are problems with LLDB's handling here. This might mean we need to have a wider discussion about how LLD does its --gc-sections. From experience working with our proprietary linker and debugger, this issue is something that both sides have to agree on. We too ended up going with an invalid address to mark the low_pc field for discarded elements.<br><br>Due to changes in how the compiler emitted DWARF information, we discovered some time ago that we cannot simply patch the high_pc field to be the same as the low_pc field, because the compiler started to use the high_pc field to indicate the size instead. Whilst this reduces the number of relocations the linker has to perform, it does make it difficult for the linker to patch the high_pc field reliably, without parsing the debug_info section.<br><br></div>Regards,<br><br><div>James<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 9 March 2017 at 11:03, Earlam, David <span dir="ltr"><<a href="mailto:dearlam@qti.qualcomm.com" target="_blank">dearlam@qti.qualcomm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi James,<br>
<br>
I performed a quick experiment with clang –g –ffunction-sections and link with –gc-sections with Hexagon DSP tools based on llvm3.5.<br>
<br>
This shows an unused function as having DW_AT_low_pc as zero as you predict:<br>
<br>
readelf –W extract of DWARF4 .debug_info)<br>
<br>
<1><2b7>: Abbrev Number: 11 (DW_TAG_subprogram)<br>
DW_AT_low_pc : 0<br>
DW_AT_high_pc : 168<br>
DW_AT_frame_base :<br>
DW_AT_name : (indirect string, offset: 0x1bb): not_used<br>
DW_AT_decl_file : 1<br>
DW_AT_decl_line : 83<br>
DW_AT_prototyped : 1<br>
DW_AT_type : <45d><br>
DW_AT_external : 1<br>
DW_AT_accessibility: 1<br>
<br>
Yet lldb 3.5.0 and lldb 3.9 both appear to _not_ ignore that DWARF DIE.<br>
<br>
(lldb) expression ¬_used<br>
(int (*)(unsigned char *, const unsigned char *, unsigned long)) $0 = 0x00000000<br>
<br>
and<br>
<br>
(lldb) breakpoint set --name not_used<br>
Breakpoint 1: where = hexlto.elf`not_used + 20 at lto_test.c:92, address = 0x00000014<br>
<br>
Line 92 would be the first statement after prolog in that source file - if the function were used - but address 0x14 is just wrong<br>
as it is inside the start-up code. I assume lldb is compensating for the instruction address offset to the first statement in that removed function.<br>
<br>
The command ‘disassemble –name not_used’ reveals the confusion - which makes it appear as though not_used() is present but does not begin with the<br>
typical Hexagon allocframe instruction that I’d expect for C and instead shows startup code.<br>
<br>
The newest llvm3.9 linker for Hexagon (an internal unreleased version here) sets the DW_AT_low_pc to a none zero value apparently far beyond the end of the .text extent which might be a hint<br>
to a DWARF consumer or a mistake.<br>
<br>
For a DW_TAG_subprogram would n’t it be more sensible for the linker to set DW_AT_low_pc and DW_AT_high_pc to the same value for garbage collected unreferenced code?<br>
>From the DWARF definition that the high_pc - when of class ADDRESS - is beyond the end of the subprogram extent - It then clearly has no machine code.<br>
Or for high_pc to also be set to 0 -when of class CONSTANT - it then clearly has no machine code.<br>
<br>
For data objects and a Harvard architecture address 0 is however valid, as weird as that may seem to C programmers. So for the Qualcomm Kalimba DSP and the XAP RISC CPU used in<br>
Bluetooth devices our proprietary debuggers look for a specific address value that we hope is greater than we ever expect to be used as a real address of any memory attached to an embedded device.<br>
<br>
As far as I know there’s no way for DWARF to convey that something has been optimised away except a DW_AT_location empty location list for a variable.<br>
<br>
Of course, a linker should be able to remove the DWARF DIEs for unreferenced code and data when it garbage collects.<br>
But I’ve not come across one that does this yet. I believe it is difficult for linker implementors because of the inter-section references and relative offsets in DWARF.<br>
<br>
Not tried with llvm 4.0 or lld or gold.<br>
<br>
<br>
David Earlam<br>
Staff-Senior[Engineer]/Manager ? Software : Development Tools() {<br>
Qualcomm Technologies International, Ltd.<br>
.<br>
<br>
From: lldb-dev [mailto:<a href="mailto:lldb-dev-bounces@lists.llvm.org">lldb-dev-bounces@<wbr>lists.llvm.org</a>] On Behalf Of James Henderson via lldb-dev<br>
Sent: 06 March 2017 13:51<br>
To: <a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a><br>
Subject: [lldb-dev] LLDB behaviour for GCed sections<br>
<div class="HOEnZb"><div class="h5"><br>
Hi,<br>
<br>
I’m currently investigating the behaviour of different debuggers when functions have been stripped by the linker because they are unused. I tried looking at the source code, but couldn’t really make enough sense of it to answer the question. Would someone be able to explain what LLDB’s behaviour is when it encounters a function in debug information with an address of zero (as is the case for lld and other linker output with --gc-sections)? In particular, does it simply ignore the relevant block of debug information, as appears to be the case for gdb? I’m coming at this from a DWARF perspective, if that makes any difference.<br>
<br>
James<br>
</div></div></blockquote></div><br></div>