perf does not resolve plt symbols from libstdc++ right (.plt.sec problem)

perf does not resolve plt symbols from libstdc++ right (.plt.sec problem)

[Jiri Slaby]

Hi,

this e-mails is a follow-up of my report at:
https://bugzilla.suse.com/show_bug.cgi?id=1180681

There is a problem with *@plt symbols in some libraries, they are 
unresolved by perf (memcmp@plt in this case):
 >     0.26%  main2    /usr/lib64/libstdc++.so.6.0.28            0xa51a0 
            l [.] 0x00000000000a51a0

On the other hand, plt symbols in other libraries are fine (memset@plt 
in this case):
 >     0.17%  main2    /usr/lib64/libantlr4-runtime.so.4.8       0x4ed10 
            l [.] memset@plt

I dumped memcmp's .plt.rela entries in perf:
/usr/lib64/libantlr4-runtime.so.4.8: 154th addr=4e9d0 plt_off=4e020 
hdr=10 entry=10
/usr/lib64/libstdc++.so.6.0.28: 772th addr=a1070 plt_off=9e020 hdr=10 
entry=10

The difference (offset) of stdc++'s memcmp is 0xa51a0 (correct) - 
0xa1070 (perf's computed) = 0x4130.

The problem is perf assumes nth entry of .plt.rela to correspond to nth 
function in .plt, but memcmp is in .plt.sec in libstdc++.so:

 > Relocation section '.rela.plt' at offset 0x97900 contains 1018 entries:
 >     Offset             Info             Type               Symbol's 
Value  Symbol's Name + Addend
 > ...
 > 00000000001dc838  0000007800000007 R_X86_64_JUMP_SLOT 
0000000000000000 memcmp@GLIBC_2.2.5 + 0

Perf does this with the rela entries:
https://github.com/torvalds/linux/blob/f5e6c330254ae691f6d7befe61c786eb5056007e/tools/perf/util/symbol-elf.c#L385

It takes a symbol index from sym.r_info. Then it resolves its name from 
.dynsym, appending "@plt" to it. Then this name is added to perf's 
symbol table along with address which is computed as .rela.plt index 
multiplied by entry size (shdr_plt.sh_entsize) plus plt header 
(shdr_plt.sh_entsize on x86_64 too).

And from this comes (almost) the offset above:
 > $ objdump -h /usr/lib64/libstdc++.so.6|grep -E ' .plt(\.sec)? '
 >  12 .plt          00003fb0  000000000009e020  000000000009e020 
0009e020  2**4
 >  14 .plt.sec      00003fa0  00000000000a2160  00000000000a2160 
000a2160  2**4

0xa2160-0x9e020 = 0x4140. I assume the 0x10 difference is that perf adds 
shdr_plt.sh_entsize (0x10) to the offset to skip the first .plt entry 
(header).

Richard writes:
======
.plt.sec is IIRC the "second" (sec) PLT entry - the one that will be 
used on the second call (and on).  This is used / emitted for ELF object 
instrumented for Intel CET.  The details escape me for the moment but I 
hope the x86 ABI documents this (and the constraints) in detail.
======

How should perf find out whether to consider .plt or .plt.sec? Or 
generally, how to properly find an address of *@plt symbols like 
memcmp@plt above?

thanks,
-- 
js
suse labs

Re: perf does not resolve plt symbols from libstdc++ right (.plt.sec problem)

[Jiri Slaby]

Any ideas on this?

On 11. 01. 21, 7:31, Jiri Slaby wrote:
> Hi,
> 
> this e-mails is a follow-up of my report at:
> https://bugzilla.suse.com/show_bug.cgi?id=1180681
> 
> There is a problem with *@plt symbols in some libraries, they are 
> unresolved by perf (memcmp@plt in this case):
>  >     0.26%  main2    /usr/lib64/libstdc++.so.6.0.28            0xa51a0 
>             l [.] 0x00000000000a51a0
> 
> On the other hand, plt symbols in other libraries are fine (memset@plt 
> in this case):
>  >     0.17%  main2    /usr/lib64/libantlr4-runtime.so.4.8       0x4ed10 
>             l [.] memset@plt
> 
> I dumped memcmp's .plt.rela entries in perf:
> /usr/lib64/libantlr4-runtime.so.4.8: 154th addr=4e9d0 plt_off=4e020 
> hdr=10 entry=10
> /usr/lib64/libstdc++.so.6.0.28: 772th addr=a1070 plt_off=9e020 hdr=10 
> entry=10
> 
> The difference (offset) of stdc++'s memcmp is 0xa51a0 (correct) - 
> 0xa1070 (perf's computed) = 0x4130.
> 
> The problem is perf assumes nth entry of .plt.rela to correspond to nth 
> function in .plt, but memcmp is in .plt.sec in libstdc++.so:
> 
>  > Relocation section '.rela.plt' at offset 0x97900 contains 1018 entries:
>  >     Offset             Info             Type               Symbol's 
> Value  Symbol's Name + Addend
>  > ...
>  > 00000000001dc838  0000007800000007 R_X86_64_JUMP_SLOT 
> 0000000000000000 memcmp@GLIBC_2.2.5 + 0
> 
> Perf does this with the rela entries:
> https://github.com/torvalds/linux/blob/f5e6c330254ae691f6d7befe61c786eb5056007e/tools/perf/util/symbol-elf.c#L385 
> 
> 
> It takes a symbol index from sym.r_info. Then it resolves its name from 
> .dynsym, appending "@plt" to it. Then this name is added to perf's 
> symbol table along with address which is computed as .rela.plt index 
> multiplied by entry size (shdr_plt.sh_entsize) plus plt header 
> (shdr_plt.sh_entsize on x86_64 too).
> 
> And from this comes (almost) the offset above:
>  > $ objdump -h /usr/lib64/libstdc++.so.6|grep -E ' .plt(\.sec)? '
>  >  12 .plt          00003fb0  000000000009e020  000000000009e020 
> 0009e020  2**4
>  >  14 .plt.sec      00003fa0  00000000000a2160  00000000000a2160 
> 000a2160  2**4
> 
> 0xa2160-0x9e020 = 0x4140. I assume the 0x10 difference is that perf adds 
> shdr_plt.sh_entsize (0x10) to the offset to skip the first .plt entry 
> (header).
> 
> Richard writes:
> ======
> .plt.sec is IIRC the "second" (sec) PLT entry - the one that will be 
> used on the second call (and on).  This is used / emitted for ELF object 
> instrumented for Intel CET.  The details escape me for the moment but I 
> hope the x86 ABI documents this (and the constraints) in detail.
> ======
> 
> How should perf find out whether to consider .plt or .plt.sec? Or 
> generally, how to properly find an address of *@plt symbols like 
> memcmp@plt above?
> 
> thanks,


-- 
js
suse labs

Re: perf does not resolve plt symbols from libstdc++ right (.plt.sec problem)

[Richard Biener]

[-- Attachment #1: Type: text/plain, Size: 3222 bytes --]

On Mon, 29 Mar 2021, Jiri Slaby wrote:

> Any ideas on this?
> 
> On 11. 01. 21, 7:31, Jiri Slaby wrote:
> > Hi,
> > 
> > this e-mails is a follow-up of my report at:
> > https://bugzilla.suse.com/show_bug.cgi?id=1180681
> > 
> > There is a problem with *@plt symbols in some libraries, they are unresolved
> > by perf (memcmp@plt in this case):
> >  >     0.26%  main2    /usr/lib64/libstdc++.so.6.0.28            0xa51a0 
> >             l [.] 0x00000000000a51a0
> > 
> > On the other hand, plt symbols in other libraries are fine (memset@plt in
> > this case):
> >  >     0.17%  main2    /usr/lib64/libantlr4-runtime.so.4.8       0x4ed10 
> >             l [.] memset@plt
> > 
> > I dumped memcmp's .plt.rela entries in perf:
> > /usr/lib64/libantlr4-runtime.so.4.8: 154th addr=4e9d0 plt_off=4e020 hdr=10
> > entry=10
> > /usr/lib64/libstdc++.so.6.0.28: 772th addr=a1070 plt_off=9e020 hdr=10
> > entry=10
> > 
> > The difference (offset) of stdc++'s memcmp is 0xa51a0 (correct) - 0xa1070
> > (perf's computed) = 0x4130.
> > 
> > The problem is perf assumes nth entry of .plt.rela to correspond to nth
> > function in .plt, but memcmp is in .plt.sec in libstdc++.so:
> > 
> >  >Relocation section '.rela.plt' at offset 0x97900 contains 1018 entries:
> >  >     Offset             Info             Type               Symbol's 
> > Value  Symbol's Name + Addend
> >  > ...
> >  > 00000000001dc838  0000007800000007 R_X86_64_JUMP_SLOT 
> > 0000000000000000 memcmp@GLIBC_2.2.5 + 0
> > 
> > Perf does this with the rela entries:
> > https://github.com/torvalds/linux/blob/f5e6c330254ae691f6d7befe61c786eb5056007e/tools/perf/util/symbol-elf.c#L385 
> > 
> > It takes a symbol index from sym.r_info. Then it resolves its name from
> > .dynsym, appending "@plt" to it. Then this name is added to perf's symbol
> > table along with address which is computed as .rela.plt index multiplied by
> > entry size (shdr_plt.sh_entsize) plus plt header (shdr_plt.sh_entsize on
> > x86_64 too).
> > 
> > And from this comes (almost) the offset above:
> >  >$ objdump -h /usr/lib64/libstdc++.so.6|grep -E ' .plt(\.sec)? '
> >  >  12 .plt          00003fb0  000000000009e020  000000000009e020 
> > 0009e020  2**4
> >  >  14 .plt.sec      00003fa0  00000000000a2160  00000000000a2160 
> > 000a2160  2**4
> > 
> > 0xa2160-0x9e020 = 0x4140. I assume the 0x10 difference is that perf adds
> > shdr_plt.sh_entsize (0x10) to the offset to skip the first .plt entry
> > (header).
> > 
> > Richard writes:
> > ======
> > .plt.sec is IIRC the "second" (sec) PLT entry - the one that will be used on
> > the second call (and on).  This is used / emitted for ELF object
> > instrumented for Intel CET.  The details escape me for the moment but I hope
> > the x86 ABI documents this (and the constraints) in detail.

I just checked and the x86_64 psABI doesn't say anything about .plt.sec

> > ======
> > 
> > How should perf find out whether to consider .plt or .plt.sec? Or generally,
> > how to properly find an address of *@plt symbols like memcmp@plt above?
> > thanks,
> 
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Re: perf does not resolve plt symbols from libstdc++ right (.plt.sec problem)

[H.J. Lu]

On Mon, Mar 29, 2021 at 2:38 AM Richard Biener <rguenther@suse.de> wrote:
>
> On Mon, 29 Mar 2021, Jiri Slaby wrote:
>
> > Any ideas on this?
> >
> > On 11. 01. 21, 7:31, Jiri Slaby wrote:
> > > Hi,
> > >
> > > this e-mails is a follow-up of my report at:
> > > https://bugzilla.suse.com/show_bug.cgi?id=1180681
> > >
> > > There is a problem with *@plt symbols in some libraries, they are unresolved
> > > by perf (memcmp@plt in this case):
> > >  >     0.26%  main2    /usr/lib64/libstdc++.so.6.0.28            0xa51a0
> > >             l [.] 0x00000000000a51a0
> > >
> > > On the other hand, plt symbols in other libraries are fine (memset@plt in
> > > this case):
> > >  >     0.17%  main2    /usr/lib64/libantlr4-runtime.so.4.8       0x4ed10
> > >             l [.] memset@plt
> > >
> > > I dumped memcmp's .plt.rela entries in perf:
> > > /usr/lib64/libantlr4-runtime.so.4.8: 154th addr=4e9d0 plt_off=4e020 hdr=10
> > > entry=10
> > > /usr/lib64/libstdc++.so.6.0.28: 772th addr=a1070 plt_off=9e020 hdr=10
> > > entry=10
> > >
> > > The difference (offset) of stdc++'s memcmp is 0xa51a0 (correct) - 0xa1070
> > > (perf's computed) = 0x4130.
> > >
> > > The problem is perf assumes nth entry of .plt.rela to correspond to nth
> > > function in .plt, but memcmp is in .plt.sec in libstdc++.so:
> > >
> > >  >Relocation section '.rela.plt' at offset 0x97900 contains 1018 entries:
> > >  >     Offset             Info             Type               Symbol's
> > > Value  Symbol's Name + Addend
> > >  > ...
> > >  > 00000000001dc838  0000007800000007 R_X86_64_JUMP_SLOT
> > > 0000000000000000 memcmp@GLIBC_2.2.5 + 0
> > >
> > > Perf does this with the rela entries:
> > > https://github.com/torvalds/linux/blob/f5e6c330254ae691f6d7befe61c786eb5056007e/tools/perf/util/symbol-elf.c#L385
> > >
> > > It takes a symbol index from sym.r_info. Then it resolves its name from
> > > .dynsym, appending "@plt" to it. Then this name is added to perf's symbol
> > > table along with address which is computed as .rela.plt index multiplied by
> > > entry size (shdr_plt.sh_entsize) plus plt header (shdr_plt.sh_entsize on
> > > x86_64 too).
> > >
> > > And from this comes (almost) the offset above:
> > >  >$ objdump -h /usr/lib64/libstdc++.so.6|grep -E ' .plt(\.sec)? '
> > >  >  12 .plt          00003fb0  000000000009e020  000000000009e020
> > > 0009e020  2**4
> > >  >  14 .plt.sec      00003fa0  00000000000a2160  00000000000a2160
> > > 000a2160  2**4
> > >
> > > 0xa2160-0x9e020 = 0x4140. I assume the 0x10 difference is that perf adds
> > > shdr_plt.sh_entsize (0x10) to the offset to skip the first .plt entry
> > > (header).
> > >
> > > Richard writes:
> > > ======
> > > .plt.sec is IIRC the "second" (sec) PLT entry - the one that will be used on
> > > the second call (and on).  This is used / emitted for ELF object
> > > instrumented for Intel CET.  The details escape me for the moment but I hope
> > > the x86 ABI documents this (and the constraints) in detail.
>
> I just checked and the x86_64 psABI doesn't say anything about .plt.sec

The second PLT is documented in section 13.2 Dynamic Linking in x86-64
psABI.  Please see elf_x86_64_get_synthetic_symtab in binutils for PLT symbol
processing.

-- 
H.J.

Re: perf does not resolve plt symbols from libstdc++ right (.plt.sec problem)

[Richard Biener]

[-- Attachment #1: Type: text/plain, Size: 3865 bytes --]

On Mon, 29 Mar 2021, H.J. Lu wrote:

> On Mon, Mar 29, 2021 at 2:38 AM Richard Biener <rguenther@suse.de> wrote:
> >
> > On Mon, 29 Mar 2021, Jiri Slaby wrote:
> >
> > > Any ideas on this?
> > >
> > > On 11. 01. 21, 7:31, Jiri Slaby wrote:
> > > > Hi,
> > > >
> > > > this e-mails is a follow-up of my report at:
> > > > https://bugzilla.suse.com/show_bug.cgi?id=1180681
> > > >
> > > > There is a problem with *@plt symbols in some libraries, they are unresolved
> > > > by perf (memcmp@plt in this case):
> > > >  >     0.26%  main2    /usr/lib64/libstdc++.so.6.0.28            0xa51a0
> > > >             l [.] 0x00000000000a51a0
> > > >
> > > > On the other hand, plt symbols in other libraries are fine (memset@plt in
> > > > this case):
> > > >  >     0.17%  main2    /usr/lib64/libantlr4-runtime.so.4.8       0x4ed10
> > > >             l [.] memset@plt
> > > >
> > > > I dumped memcmp's .plt.rela entries in perf:
> > > > /usr/lib64/libantlr4-runtime.so.4.8: 154th addr=4e9d0 plt_off=4e020 hdr=10
> > > > entry=10
> > > > /usr/lib64/libstdc++.so.6.0.28: 772th addr=a1070 plt_off=9e020 hdr=10
> > > > entry=10
> > > >
> > > > The difference (offset) of stdc++'s memcmp is 0xa51a0 (correct) - 0xa1070
> > > > (perf's computed) = 0x4130.
> > > >
> > > > The problem is perf assumes nth entry of .plt.rela to correspond to nth
> > > > function in .plt, but memcmp is in .plt.sec in libstdc++.so:
> > > >
> > > >  >Relocation section '.rela.plt' at offset 0x97900 contains 1018 entries:
> > > >  >     Offset             Info             Type               Symbol's
> > > > Value  Symbol's Name + Addend
> > > >  > ...
> > > >  > 00000000001dc838  0000007800000007 R_X86_64_JUMP_SLOT
> > > > 0000000000000000 memcmp@GLIBC_2.2.5 + 0
> > > >
> > > > Perf does this with the rela entries:
> > > > https://github.com/torvalds/linux/blob/f5e6c330254ae691f6d7befe61c786eb5056007e/tools/perf/util/symbol-elf.c#L385
> > > >
> > > > It takes a symbol index from sym.r_info. Then it resolves its name from
> > > > .dynsym, appending "@plt" to it. Then this name is added to perf's symbol
> > > > table along with address which is computed as .rela.plt index multiplied by
> > > > entry size (shdr_plt.sh_entsize) plus plt header (shdr_plt.sh_entsize on
> > > > x86_64 too).
> > > >
> > > > And from this comes (almost) the offset above:
> > > >  >$ objdump -h /usr/lib64/libstdc++.so.6|grep -E ' .plt(\.sec)? '
> > > >  >  12 .plt          00003fb0  000000000009e020  000000000009e020
> > > > 0009e020  2**4
> > > >  >  14 .plt.sec      00003fa0  00000000000a2160  00000000000a2160
> > > > 000a2160  2**4
> > > >
> > > > 0xa2160-0x9e020 = 0x4140. I assume the 0x10 difference is that perf adds
> > > > shdr_plt.sh_entsize (0x10) to the offset to skip the first .plt entry
> > > > (header).
> > > >
> > > > Richard writes:
> > > > ======
> > > > .plt.sec is IIRC the "second" (sec) PLT entry - the one that will be used on
> > > > the second call (and on).  This is used / emitted for ELF object
> > > > instrumented for Intel CET.  The details escape me for the moment but I hope
> > > > the x86 ABI documents this (and the constraints) in detail.
> >
> > I just checked and the x86_64 psABI doesn't say anything about .plt.sec
> 
> The second PLT is documented in section 13.2 Dynamic Linking in x86-64
> psABI.  Please see elf_x86_64_get_synthetic_symtab in binutils for PLT symbol
> processing.

Hmm, google pointed me to https://gitlab.com/x86-psABIs/ and that
version does not have a section 13 (but the last is section 12 on MPX).
There's also references to a pdf which contain the section but
that's on github and the github page says gitlab is the home...
So I'm a bit confused here.

Richard.

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Re: perf does not resolve plt symbols from libstdc++ right (.plt.sec problem)

[H.J. Lu]

On Mon, Mar 29, 2021 at 6:06 AM Richard Biener <rguenther@suse.de> wrote:
>
> On Mon, 29 Mar 2021, H.J. Lu wrote:
>
> > On Mon, Mar 29, 2021 at 2:38 AM Richard Biener <rguenther@suse.de> wrote:
> > >
> > > On Mon, 29 Mar 2021, Jiri Slaby wrote:
> > >
> > > > Any ideas on this?
> > > >
> > > > On 11. 01. 21, 7:31, Jiri Slaby wrote:
> > > > > Hi,
> > > > >
> > > > > this e-mails is a follow-up of my report at:
> > > > > https://bugzilla.suse.com/show_bug.cgi?id=1180681
> > > > >
> > > > > There is a problem with *@plt symbols in some libraries, they are unresolved
> > > > > by perf (memcmp@plt in this case):
> > > > >  >     0.26%  main2    /usr/lib64/libstdc++.so.6.0.28            0xa51a0
> > > > >             l [.] 0x00000000000a51a0
> > > > >
> > > > > On the other hand, plt symbols in other libraries are fine (memset@plt in
> > > > > this case):
> > > > >  >     0.17%  main2    /usr/lib64/libantlr4-runtime.so.4.8       0x4ed10
> > > > >             l [.] memset@plt
> > > > >
> > > > > I dumped memcmp's .plt.rela entries in perf:
> > > > > /usr/lib64/libantlr4-runtime.so.4.8: 154th addr=4e9d0 plt_off=4e020 hdr=10
> > > > > entry=10
> > > > > /usr/lib64/libstdc++.so.6.0.28: 772th addr=a1070 plt_off=9e020 hdr=10
> > > > > entry=10
> > > > >
> > > > > The difference (offset) of stdc++'s memcmp is 0xa51a0 (correct) - 0xa1070
> > > > > (perf's computed) = 0x4130.
> > > > >
> > > > > The problem is perf assumes nth entry of .plt.rela to correspond to nth
> > > > > function in .plt, but memcmp is in .plt.sec in libstdc++.so:
> > > > >
> > > > >  >Relocation section '.rela.plt' at offset 0x97900 contains 1018 entries:
> > > > >  >     Offset             Info             Type               Symbol's
> > > > > Value  Symbol's Name + Addend
> > > > >  > ...
> > > > >  > 00000000001dc838  0000007800000007 R_X86_64_JUMP_SLOT
> > > > > 0000000000000000 memcmp@GLIBC_2.2.5 + 0
> > > > >
> > > > > Perf does this with the rela entries:
> > > > > https://github.com/torvalds/linux/blob/f5e6c330254ae691f6d7befe61c786eb5056007e/tools/perf/util/symbol-elf.c#L385
> > > > >
> > > > > It takes a symbol index from sym.r_info. Then it resolves its name from
> > > > > .dynsym, appending "@plt" to it. Then this name is added to perf's symbol
> > > > > table along with address which is computed as .rela.plt index multiplied by
> > > > > entry size (shdr_plt.sh_entsize) plus plt header (shdr_plt.sh_entsize on
> > > > > x86_64 too).
> > > > >
> > > > > And from this comes (almost) the offset above:
> > > > >  >$ objdump -h /usr/lib64/libstdc++.so.6|grep -E ' .plt(\.sec)? '
> > > > >  >  12 .plt          00003fb0  000000000009e020  000000000009e020
> > > > > 0009e020  2**4
> > > > >  >  14 .plt.sec      00003fa0  00000000000a2160  00000000000a2160
> > > > > 000a2160  2**4
> > > > >
> > > > > 0xa2160-0x9e020 = 0x4140. I assume the 0x10 difference is that perf adds
> > > > > shdr_plt.sh_entsize (0x10) to the offset to skip the first .plt entry
> > > > > (header).
> > > > >
> > > > > Richard writes:
> > > > > ======
> > > > > .plt.sec is IIRC the "second" (sec) PLT entry - the one that will be used on
> > > > > the second call (and on).  This is used / emitted for ELF object
> > > > > instrumented for Intel CET.  The details escape me for the moment but I hope
> > > > > the x86 ABI documents this (and the constraints) in detail.
> > >
> > > I just checked and the x86_64 psABI doesn't say anything about .plt.sec
> >
> > The second PLT is documented in section 13.2 Dynamic Linking in x86-64
> > psABI.  Please see elf_x86_64_get_synthetic_symtab in binutils for PLT symbol
> > processing.
>
> Hmm, google pointed me to https://gitlab.com/x86-psABIs/ and that
> version does not have a section 13 (but the last is section 12 on MPX).
> There's also references to a pdf which contain the section but
> that's on github and the github page says gitlab is the home...
> So I'm a bit confused here.
>

https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/13


-- 
H.J.

Re: perf does not resolve plt symbols from libstdc++ right (.plt.sec problem)

[Jiri Slaby]

On 29. 03. 21, 15:10, H.J. Lu wrote:
> On Mon, Mar 29, 2021 at 6:06 AM Richard Biener <rguenther@suse.de> wrote:
>>
>> On Mon, 29 Mar 2021, H.J. Lu wrote:
>>
>>> On Mon, Mar 29, 2021 at 2:38 AM Richard Biener <rguenther@suse.de> wrote:
>>>>
>>>> On Mon, 29 Mar 2021, Jiri Slaby wrote:
>>>>
>>>>> Any ideas on this?
>>>>>
>>>>> On 11. 01. 21, 7:31, Jiri Slaby wrote:
>>>>>> Hi,
>>>>>>
>>>>>> this e-mails is a follow-up of my report at:
>>>>>> https://bugzilla.suse.com/show_bug.cgi?id=1180681
>>>>>>
>>>>>> There is a problem with *@plt symbols in some libraries, they are unresolved
>>>>>> by perf (memcmp@plt in this case):
>>>>>>   >     0.26%  main2    /usr/lib64/libstdc++.so.6.0.28            0xa51a0
>>>>>>              l [.] 0x00000000000a51a0
>>>>>>
>>>>>> On the other hand, plt symbols in other libraries are fine (memset@plt in
>>>>>> this case):
>>>>>>   >     0.17%  main2    /usr/lib64/libantlr4-runtime.so.4.8       0x4ed10
>>>>>>              l [.] memset@plt
>>>>>>
>>>>>> I dumped memcmp's .plt.rela entries in perf:
>>>>>> /usr/lib64/libantlr4-runtime.so.4.8: 154th addr=4e9d0 plt_off=4e020 hdr=10
>>>>>> entry=10
>>>>>> /usr/lib64/libstdc++.so.6.0.28: 772th addr=a1070 plt_off=9e020 hdr=10
>>>>>> entry=10
>>>>>>
>>>>>> The difference (offset) of stdc++'s memcmp is 0xa51a0 (correct) - 0xa1070
>>>>>> (perf's computed) = 0x4130.
>>>>>>
>>>>>> The problem is perf assumes nth entry of .plt.rela to correspond to nth
>>>>>> function in .plt, but memcmp is in .plt.sec in libstdc++.so:
>>>>>>
>>>>>>   >Relocation section '.rela.plt' at offset 0x97900 contains 1018 entries:
>>>>>>   >     Offset             Info             Type               Symbol's
>>>>>> Value  Symbol's Name + Addend
>>>>>>   > ...
>>>>>>   > 00000000001dc838  0000007800000007 R_X86_64_JUMP_SLOT
>>>>>> 0000000000000000 memcmp@GLIBC_2.2.5 + 0
>>>>>>
>>>>>> Perf does this with the rela entries:
>>>>>> https://github.com/torvalds/linux/blob/f5e6c330254ae691f6d7befe61c786eb5056007e/tools/perf/util/symbol-elf.c#L385
>>>>>>
>>>>>> It takes a symbol index from sym.r_info. Then it resolves its name from
>>>>>> .dynsym, appending "@plt" to it. Then this name is added to perf's symbol
>>>>>> table along with address which is computed as .rela.plt index multiplied by
>>>>>> entry size (shdr_plt.sh_entsize) plus plt header (shdr_plt.sh_entsize on
>>>>>> x86_64 too).
>>>>>>
>>>>>> And from this comes (almost) the offset above:
>>>>>>   >$ objdump -h /usr/lib64/libstdc++.so.6|grep -E ' .plt(\.sec)? '
>>>>>>   >  12 .plt          00003fb0  000000000009e020  000000000009e020
>>>>>> 0009e020  2**4
>>>>>>   >  14 .plt.sec      00003fa0  00000000000a2160  00000000000a2160
>>>>>> 000a2160  2**4
>>>>>>
>>>>>> 0xa2160-0x9e020 = 0x4140. I assume the 0x10 difference is that perf adds
>>>>>> shdr_plt.sh_entsize (0x10) to the offset to skip the first .plt entry
>>>>>> (header).
>>>>>>
>>>>>> Richard writes:
>>>>>> ======
>>>>>> .plt.sec is IIRC the "second" (sec) PLT entry - the one that will be used on
>>>>>> the second call (and on).  This is used / emitted for ELF object
>>>>>> instrumented for Intel CET.  The details escape me for the moment but I hope
>>>>>> the x86 ABI documents this (and the constraints) in detail.
>>>>
>>>> I just checked and the x86_64 psABI doesn't say anything about .plt.sec
>>>
>>> The second PLT is documented in section 13.2 Dynamic Linking in x86-64
>>> psABI.  Please see elf_x86_64_get_synthetic_symtab in binutils for PLT symbol
>>> processing.
>>
>> Hmm, google pointed me to https://gitlab.com/x86-psABIs/ and that
>> version does not have a section 13 (but the last is section 12 on MPX).
>> There's also references to a pdf which contain the section but
>> that's on github and the github page says gitlab is the home...
>> So I'm a bit confused here.
>>
> 
> https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/13

Ok, so it talks only about GOT:
===
When the IBT-enabled procedure linkage table is used, the initial value 
of the global offset table entry for the external function is the 
address of the corresponding entry of the second procedure linkage table.
===

GOTs are now related to .plt.sec. But my question about .plt.rela 
remains unanswered by the above:
 > The problem is perf assumes nth entry of .plt.rela to correspond to nth
 > function in .plt, but memcmp is in .plt.sec in libstdc++.so

So how one finds out whether .rela entries belong to .plt or .plt.sec? 
Or should we assume that with .plt.sec, .plt.rela always points to .plt.sec?

thanks,
-- 
js
suse labs