[Bug lto/98971] LTO removes __patchable_function_entries

marxin at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Fri Feb 5 12:18:56 GMT 2021


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98971

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Created attachment 50133
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50133&action=edit
Tentative patch

As seen the flag -fpatchable-function-entry is properly marked as Optimization.
However, it's the argument is parsed early and stored into the following tuple:

; How many NOP insns to place at each function entry by default
Variable
HOST_WIDE_INT function_entry_patch_area_size

; And how far the real asm entry point is into this area
Variable
HOST_WIDE_INT function_entry_patch_area_start

That does not work with set_current_function where per-function arguments are
restored. My tentative patch fixes that.

The following examples works now:

$ cat pr98971.c
int
testa7(void)
{
  return 7;
}

int
__attribute__((patchable_function_entry(10,5)))
testa77(void)
{
  return 77;
}

#pragma GCC optimize("patchable-function-entry=0,0")

int
testa_no(void)
{
  return 1234;
}

$ cat pr98971-2.c
int
testa8(void)
{
  return 8;
}

$ gcc pr98971.c -fPIC -fpatchable-function-entry=4,1 -flto -c
$ gcc pr98971-2.c -fPIC -flto -c
$ gcc pr98971.o pr98971-2.o -flto -shared -o x.so
$ objdump -d x.so
...
0000000000000650 <frame_dummy>:
 650:   f3 0f 1e fa             endbr64 
 654:   e9 77 ff ff ff          jmp    5d0 <register_tm_clones>
 659:   90                      nop

000000000000065a <testa7>:
 65a:   90                      nop
 65b:   90                      nop
 65c:   90                      nop
 65d:   55                      push   %rbp
 65e:   48 89 e5                mov    %rsp,%rbp
 661:   b8 07 00 00 00          mov    $0x7,%eax
 666:   5d                      pop    %rbp
 667:   c3                      ret    
 668:   90                      nop
 669:   90                      nop
 66a:   90                      nop
 66b:   90                      nop
 66c:   90                      nop

000000000000066d <testa77>:
 66d:   90                      nop
 66e:   90                      nop
 66f:   90                      nop
 670:   90                      nop
 671:   90                      nop
 672:   55                      push   %rbp
 673:   48 89 e5                mov    %rsp,%rbp
 676:   b8 4d 00 00 00          mov    $0x4d,%eax
 67b:   5d                      pop    %rbp
 67c:   c3                      ret    

000000000000067d <testa_no>:
 67d:   55                      push   %rbp
 67e:   48 89 e5                mov    %rsp,%rbp
 681:   b8 d2 04 00 00          mov    $0x4d2,%eax
 686:   5d                      pop    %rbp
 687:   c3                      ret    

0000000000000688 <testa8>:
 688:   55                      push   %rbp
 689:   48 89 e5                mov    %rsp,%rbp
 68c:   b8 08 00 00 00          mov    $0x8,%eax
 691:   5d                      pop    %rbp
 692:   c3                      ret    

@Gabriel: Is it intended behavior?


More information about the Gcc-bugs mailing list