| Message ID | 20171018072404.GE14653@tucnak |
|---|---|
| State | New |
| Headers | show |
| Series | Fix PT_GNU_STACK on LTO compiled binaries with debug info (PR lto/82598) | expand |
On Wed, 18 Oct 2017, Jakub Jelinek wrote: > Hi! > > 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 non-executable stack on debug objects? Or as you say clear SHF_EXECINSTR (whatever that means)? That would also be more portable to non-GNU targets? After all the note doesn't really tell anything about the debug part but about the fat part (or the pointless .text section we always emit in slim objects). Richard. > 2017-10-18 Jakub Jelinek <jakub@redhat.com> > > PR lto/82598 > * simple-object.c (handle_lto_debug_sections): Copy over also > .note.GNU-stack section with unchanged name. > > --- libiberty/simple-object.c.jj 2017-09-01 09:27:00.000000000 +0200 > +++ libiberty/simple-object.c 2017-10-18 09:15:51.088756028 +0200 > @@ -273,6 +273,9 @@ handle_lto_debug_sections (const char ** > *name = *name + sizeof (".gnu.lto_") - 1; > return 1; > } > + /* Copy over .note.GNU-stack section under the same name if present. */ > + else if (strcmp (*name, ".note.GNU-stack") == 0) > + return 1; > return 0; > } > > > Jakub > >
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
--- libiberty/simple-object.c.jj 2017-09-01 09:27:00.000000000 +0200 +++ libiberty/simple-object.c 2017-10-18 09:15:51.088756028 +0200 @@ -273,6 +273,9 @@ handle_lto_debug_sections (const char ** *name = *name + sizeof (".gnu.lto_") - 1; return 1; } + /* Copy over .note.GNU-stack section under the same name if present. */ + else if (strcmp (*name, ".note.GNU-stack") == 0) + return 1; return 0; }