From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id E6B9E39D2C62; Thu,  4 Feb 2021 21:37:20 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E6B9E39D2C62
From: "gabriel at inconstante dot net.br" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/98971] New: LTO removes __patchable_function_entries
Date: Thu, 04 Feb 2021 21:37:20 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: gabriel at inconstante dot net.br
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter cc target_milestone
Message-ID: <bug-98971-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Feb 2021 21:37:21 -0000

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

            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=3D4,2 -flto -c -o libtest=
a.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 result=
ing
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=3D4,2 -flto -shared -o
libtesta.so

also works as I expected, i.e.: the nops and the __patchable_function_entri=
es
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 f=
rom
openSUSE and Debian.=