GNU Tools Cauldron SFrame talk notes

[Florian Weimer]

* Fangrui Song:

>> I am also not sure ATM about how will this fit in the linker workflow
>> (and if managing this itself brings additional section specific handling
>> in the generic linker parts): There are linker generated .eh_frame
>> sections (for .plt* sections), which are merged to create the final
>> .eh_frame output.  The suggested process of SFrame data creation will
>> need to be deferred until such merging of EH Frame data is complete...
>
> I think --ld-generated-unwind-info is a legacy feature
> https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#no-ld-generated-unwind-info

I think the way this works today in BFD ld (for x86-64) is that it
creates a single FDE that covers all PLT stubs/trampolines.  The CFI
program for it looks at the lowest 4 bits of the instruction pointer and
uses that to determine to adjust the frame address.

I'm not sure if this is still needed today because I doubt we need to
support anything BIND_NOW for new binaries.

>     However, I think this feature is obsolete and no longer relevant.
> To recognize the PLT name, a profiler needs to:
>
>     Parse the .plt section to identify the region of PLT entries
>     Parse .rel[a].plt to get R_*_JUMP_SLOT dynamic relocations and
> their referenced symbol names
>     If the current PC is within the PLT region, parse nearby
> instructions and find the GOT load. The associated R_*_JUMP_SLOT
> identifies the symbol name
>     Concatenate the symbol name and @plt to form foo@plt
>     Note: foo@plt is a convention used by some tools, but it is not a
> name in the symbol table.
>
>     gdb has heuristics to identify this situation.

We now have PLT rewriting because indirect branch predictors are not
that great on some CPUs (limited capacity, especially for branch target
distances greater than 64 MiB on certain implementations).  These
patterns would have to adapted to that.

Thanks,
Florian