Hi James,
I performed a quick experiment with clang –g –ffunction-sections and link with
–gc-sections with Hexagon DSP tools based on llvm3.5.
This shows an unused function as having DW_AT_low_pc as zero as you predict:
readelf –W extract of DWARF4 .debug_info)
<1><2b7>: Abbrev Number: 11 (DW_TAG_subprogram)
DW_AT_low_pc : 0
DW_AT_high_pc : 168
DW_AT_frame_base :
DW_AT_name : (indirect string, offset: 0x1bb): not_used
DW_AT_decl_file : 1
DW_AT_decl_line : 83
DW_AT_prototyped : 1
DW_AT_type : <45d>
DW_AT_external : 1
DW_AT_accessibility: 1
Yet lldb 3.5.0 and lldb 3.9 both appear to _not_ ignore that DWARF DIE.
(lldb) expression ¬_used
(int (*)(unsigned char *, const unsigned char *, unsigned long)) $0 = 0x00000000
and
(lldb) breakpoint set --name not_used
Breakpoint 1: where = hexlto.elf`not_used + 20 at lto_test.c:92, address =
0x00000014
Line 92 would be the first statement after prolog in that source file - if the
function were used - but address 0x14 is just wrong
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.
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
typical Hexagon allocframe instruction that I’d expect for C and instead shows
startup code.
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
to a DWARF consumer or a mistake.
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?
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.
Or for high_pc to also be set to 0 -when of class CONSTANT - it then clearly
has no machine code.
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
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.
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.
Of course, a linker should be able to remove the DWARF DIEs for unreferenced
code and data when it garbage collects.
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.
Not tried with llvm 4.0 or lld or gold.
David Earlam
Staff-Senior[Engineer]/Manager ? Software : Development Tools() {
Qualcomm Technologies International, Ltd.
.
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of James
Henderson via lldb-dev
Sent: 06 March 2017 13:51
To: lldb-dev@lists.llvm.org
Subject: [lldb-dev] LLDB behaviour for GCed sections
Hi,
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.
James
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
