This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PT_GNU_STACK on LTO compiled binaries with debug info (PR lto/82598)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Ian Lance Taylor <ian at airs dot com>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 18 Oct 2017 10:20:20 +0200
- Subject: Re: [PATCH] Fix PT_GNU_STACK on LTO compiled binaries with debug info (PR lto/82598)
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jakub at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3AEDF33A17A
- References: <20171018072404.GE14653@tucnak> <alpine.LSU.2.20.1710181012390.5588@zhemvz.fhfr.qr>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Oct 18, 2017 at 10:15:21AM +0200, Richard Biener wrote:
> On Wed, 18 Oct 2017, Jakub Jelinek wrote:
> > When creating lto debugobj, we copy over just the debug sections,
> > and from the lack of .note.GNU-stack section then on various targets
> > the linker implies RWE PT_GNU_STACK segment header.
>
> Uh. But those objects don't even have a .text section...
>
> > Fixed by copying over also the .note.GNU-stack section if present.
> > It is not 100% perfect solution if .note.GNU-stack in the original
> > indicates executable stack, in the debugobj we really don't need
> > it, so could get away with clearing the SHF_EXECINSTR bit, but in reality
> > it shouldn't be that bad, if the source had trampolines, then likely the
> > LTO objects will have them too.
> >
> > Tested on x86_64-linux, ok for trunk?
>
> Can't we simply always append a .note.GNU-stack to indicate a
No. .note.GNU-stack is only added on some targets, on other targets it
isn't, so if the linker will see the note on some target where it isn't
normally seen, it will force different behavior than it used to have
normally upon all the other objects.
> non-executable stack on debug objects? Or as you say clear
> SHF_EXECINSTR (whatever that means)?
See the second patch I've posted which does that.
Jakub