[Bug lto/98971] New: LTO removes __patchable_function_entries
gabriel at inconstante dot net.br
gcc-bugzilla@gcc.gnu.org
Thu Feb 4 21:37:20 GMT 2021
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98971
Bug ID: 98971
Summary: LTO removes __patchable_function_entries
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: gabriel at inconstante dot net.br
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Building with -flto removes the effects of -fpatchable-function-entries, or at
least some of them.
For instance, building the following code:
$ cat libtesta.c
int
testa7(void)
{
return 7;
}
with:
$ gcc libtesta.c -fPIC -fpatchable-function-entry=4,2 -flto -c -o libtesta.o
$ gcc libtesta.o -flto -shared -o libtesta.so
removes the nop padding usually generated with -fpatchable-function-entry, as
well as it removes the __patchable_function_entries section from the resulting
binaries. The intermediate libtesta.o already lacks both:
$ readelf --sections libtesta.o | grep __patchable
$ readelf --sections libtesta.so | grep __patchable
$ objdump -d libtesta.so | grep "<testa7>:" -C3
00000000000010f0 <frame_dummy>:
10f0: e9 7b ff ff ff jmpq 1070 <register_tm_clones>
00000000000010f5 <testa7>:
10f5: 55 push %rbp
10f6: 48 89 e5 mov %rsp,%rbp
10f9: b8 07 00 00 00 mov $0x7,%eax
Without -flto, I get what I expected:
$ readelf --sections libtesta.o | grep __patchable
[ 4] __patchable_[...] PROGBITS 0000000000000000 00000050
$ readelf --sections libtesta.so | grep __patchable
[19] __patchable_[...] PROGBITS 0000000000004020 00003020
$ objdump -d libtesta.so | grep "<testa7>:" -C3
10f5: 90 nop
10f6: 90 nop
00000000000010f7 <testa7>:
10f7: 90 nop
10f8: 90 nop
10f9: 55 push %rbp
Building with a single gcc command, such as:
$ gcc libtesta.c -fPIC -fpatchable-function-entry=4,2 -flto -shared -o
libtesta.so
also works as I expected, i.e.: the nops and the __patchable_function_entries
are kept.
Is this the intended behavior? Am I using it wrong? Or is this a bug?
Cheers
PS: Tested with the branch for gcc 10, with trunk, and with the compilers from
openSUSE and Debian.
More information about the Gcc-bugs
mailing list