Re: RFC: Unwind info for PLT

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Fri, 10 Jun 2011 09:45:24 +0200
> From: Jakub Jelinek <jakub@redhat.com>
> 
> Hi!
> 
> gdb apparently has some code to default to a certain unwind info if
> no FDE is found, as b 'f0001@plt'; c; bt; works and stepi; bt; works
> too, but next stepi; bt; already gives
> #0  0x0000000000494f73 in f0001@plt ()
> #1  0x0000000000000be7 in ?? ()
> #2  0x00000000004b03d8 in main () at prg1.c:29
> instead of
> #0  0x0000000000494f73 in f0001@plt ()
> #1  0x00000000004b03d8 in main () at prg1.c:29
> But when doing b 'f0002@plt'; c; then kill -USR1 `pidof prg1` from
> another terminal and then continuing, the backtrace shown stops in
> the plt and doesn't go back.

Typically PLT entries are handled by unwinders that analyze the code,
either by the default unwinder that does standard prologue analysis
(sparc/sparc64) or a dedicated unwinder (s390 for example).  For most
targets this isn't a big issue, since the PLT stubs are typically
defined by the appropriate ABI.  Generally the most difficult part is
to figure out where the PLT entries actually start since linkers are a
bit inconsistent in choosing symbol names for the start of the PLT,
and not all targets have a proper .plt section.

Looks like we don't do a particular good job on amd64 though.  Seems
nobody actually bothered to do this properly for i386/amd64, probably
because it mostly works without special code.

> I wonder whether ld couldn't synthetize unwind info for the .plt
> section (perhaps with some option),

A potential problem here is that the PLT entries get patched up by the
dynamic linker.  You must make sure that the unwind info is correct
for both the unpacthed and patched versions of the PLT entries.  That
may not be possible.  But otherwise I think this is a sound idea.

> or alternatively if it couldn't just provide hidden
> __PLT_START__/__PLT_END__ or similar symbols and the unwind info
> couldn't be written in glibc crtfiles linked into it.

I don't think I fully understand what you're trying to say here.
Sounds complicated/fragile.  The canonical name for the start of the
PLT is _PROCEDURE_LINKAGE_TABLE_, but as I said the PLT isn't
consistently named across toolchains.  I think for GNU ld, the name is
assigned by a linker script, which people tend to replace by something
they've written themselves.

> 00000035e7a1ec60 <calloc@plt>:
>   35e7a1ec60:   ff 25 9a 33 37 00       jmpq   *0x37339a(%rip)        # 35e7d92000 <_GLOBAL_OFFSET_TABLE_+0x18>
>   35e7a1ec66:   68 00 00 00 00          pushq  $0x0
>   35e7a1ec6b:   e9 e0 ff ff ff          jmpq   35e7a1ec50 <data.9331+0x35e7a1ebc8>

That pushq instruction is the reason you get that weird backtrace.

> Anyway, I think hardcoding this in the linker would be problematic,
> we couldn't tweak it, so providing some special hidden symbols around
> the .plt section and let glibc crtfiles provide it sounds like the best
> option to me.

Well, the linker is the one generating/inserting the PLT entries.  So
it should know how to generate unwind infor for them.  I really don't
see how you could make sure that the description provided the crtfiles
are consistent with what the linker generated.