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
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
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 <[email protected]>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imend?rffer; HRB 36809 (AG Nuernberg)
On Mon, Mar 29, 2021 at 2:38 AM Richard Biener <[email protected]> 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.
On Mon, 29 Mar 2021, H.J. Lu wrote:
> On Mon, Mar 29, 2021 at 2:38 AM Richard Biener <[email protected]> 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 <[email protected]>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On Mon, Mar 29, 2021 at 6:06 AM Richard Biener <[email protected]> wrote:
>
> On Mon, 29 Mar 2021, H.J. Lu wrote:
>
> > On Mon, Mar 29, 2021 at 2:38 AM Richard Biener <[email protected]> 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.
On 29. 03. 21, 15:10, H.J. Lu wrote:
> On Mon, Mar 29, 2021 at 6:06 AM Richard Biener <[email protected]> wrote:
>>
>> On Mon, 29 Mar 2021, H.J. Lu wrote:
>>
>>> On Mon, Mar 29, 2021 at 2:38 AM Richard Biener <[email protected]> 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