https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to R. Diez from comment #3)
> Regarding "shifting the blame", no worries, I am grateful for any help.
>
> I suspect that there is more than 1 issue here. Could you take a look at the
> following aspect mentioned in the GDB bug?
>
> ----8<----8<----
>
> In fact, I do not understand why StartOfUserCode is not defined in the
> release build, because it is the same source code after all. The same
> routine is used in the same way.
>From just looking at the debug info I see it is inlined into
RunUserCode and the offline copy is elided (it's not used from elsewhere).
Hint: readelf -w dumps the debug info, you see
<1><203aa>: Abbrev Number: 91 (DW_TAG_subprogram)
<203ab> DW_AT_external : 1
<203ab> DW_AT_name : (indirect string, offset: 0x7d561):
StartOfUserCode
...
this is the abstract DIE so look for '203aa' and find
<1><e157>: Abbrev Number: 37 (DW_TAG_subprogram)
<e158> DW_AT_abstract_origin: <0x15d6a>
<e15c> DW_AT_low_pc : 0x860c8
<e160> DW_AT_high_pc : 0x9d0
<e164> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<e166> DW_AT_GNU_all_tail_call_sites: 1
<e166> DW_AT_sibling : <0xfeeb>
<2><e16a>: Abbrev Number: 8 (DW_TAG_inlined_subroutine)
<e16b> DW_AT_abstract_origin: <0x203aa>
<e16f> DW_AT_entry_pc : 0x860c8
aha, so inlined into e157 - that's a concrete DIE so look for it's
abstract origin 15d6a and find:
<1><15d6a>: Abbrev Number: 13 (DW_TAG_subprogram)
<15d6b> DW_AT_external : 1
<15d6b> DW_AT_name : (indirect string, offset: 0x69052):
RunUserCode
...
> I dumped all symbols like this and I compared them:
>
> arm-none-eabi-objdump --syms firmware-debug-non-lto.elf
> arm-none-eabi-objdump --syms firmware-release-lto.elf
>
> ----8<----8<----
>
> That particular symbol, StartOfUserCode, among many others, should be in the
> release build too. And there is no GDB involved there at all.
>
> I have not got experience with clang or lldb at all, and I have read that
> lldb is not ready yet for debugging bare metal firmware (at least off the
> shelf).
Might be - I've not used lldb myself either.
