Re: glibc 2.36 *.o files debug extraction broken
On 16.08.2022 21:53, Jakub Bogusz wrote: > On Tue, Aug 16, 2022 at 09:28:58PM +0200, Jan Palus wrote: > > On 16.08.2022 20:31, Jakub Bogusz wrote: > > > In glibc 2.36 build debuginfo extraction process removes .note.GNU-stack > > > section: > > > > ... > > > > > For now only i686 builds are affected because x86_64 and x32 glibc-devel > > > packages > > > haven't been updated on builders. > > > > > > > > > Any guesses what changed? > > > > I believe to be responsible for this, specifically with this debugedit > > commit: > > > > commit bd392272c04d608257eb999670d85261d5125d93 > > Author: Jan Palus > > Date: Tue Jun 7 11:39:01 2022 > > > > bring back patch from rpm 4.16 for no exe bit when searching debuginfo; > > rel 2 > > > > which now considers non-executable object file matching pattern > > found in `find-debuginfo`: ^\(.*\):[ ]*.*ELF.*, not stripped.* > > > > Which in turn causes object file to be passed to `eu-strip` directly > > responsible for stripping .note.GNU-stack section. > > > > Fix proposals: > > > > 1. modify `find-debuginfo` pattern to include ELF.*\(executable\|shared > > object\) > > 2. modify macros to invoke `find-debuginfo` with `--keep-section > > .note.GNU-stack` > > 3. both 1 and 2 > > I think it would be safer to revert to not touching *.o files (by > default). For the time being implemented 1. not to regress packages initial fix was done for. > BTW, why find-debuginfo removes .note.GNU-stack from *.o and doesn't remove > from *.a/*.so? To be precise it's eu-strip that find-debuginfo invokes. Regarding actual question these are two different things: object files (*.o) hold information for linker in .note.GNU-stack section of ELF file. Linker uses this information when creating shared objects (*.so) or executables to construct GNU_STACK program header in output ELF file. GNU_STACK is in turn used by kernel. eu-strip does not touch ELF program headers at all so it's plain copy. It only operates on ELF sections. So that's why executable/so files are not affected. (note that mentioned archives (*.a) are not considered for debuginfo extraction). I see a comment in elfutils strip code that intention was to keep all ELF notes, which while implemented, does not affect .note.GNU-stack. Most notes appear to be of type SHT_NOTE (that's what implementation relies on) however .note.GNU-stack is of type SHT_PROGBITS (ref elf(5)). I will raise a question to elfutils whether this is intended. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: glibc 2.36 *.o files debug extraction broken
On Tue, Aug 16, 2022 at 09:28:58PM +0200, Jan Palus wrote: > On 16.08.2022 20:31, Jakub Bogusz wrote: > > In glibc 2.36 build debuginfo extraction process removes .note.GNU-stack > > section: > > ... > > > For now only i686 builds are affected because x86_64 and x32 glibc-devel > > packages > > haven't been updated on builders. > > > > > > Any guesses what changed? > > I believe to be responsible for this, specifically with this debugedit > commit: > > commit bd392272c04d608257eb999670d85261d5125d93 > Author: Jan Palus > Date: Tue Jun 7 11:39:01 2022 > > bring back patch from rpm 4.16 for no exe bit when searching debuginfo; > rel 2 > > which now considers non-executable object file matching pattern > found in `find-debuginfo`: ^\(.*\):[ ]*.*ELF.*, not stripped.* > > Which in turn causes object file to be passed to `eu-strip` directly > responsible for stripping .note.GNU-stack section. > > Fix proposals: > > 1. modify `find-debuginfo` pattern to include ELF.*\(executable\|shared > object\) > 2. modify macros to invoke `find-debuginfo` with `--keep-section > .note.GNU-stack` > 3. both 1 and 2 I think it would be safer to revert to not touching *.o files (by default). BTW, why find-debuginfo removes .note.GNU-stack from *.o and doesn't remove from *.a/*.so? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: glibc 2.36 *.o files debug extraction broken
On 16.08.2022 20:31, Jakub Bogusz wrote: > In glibc 2.36 build debuginfo extraction process removes .note.GNU-stack > section: ... > For now only i686 builds are affected because x86_64 and x32 glibc-devel > packages > haven't been updated on builders. > > > Any guesses what changed? I believe to be responsible for this, specifically with this debugedit commit: commit bd392272c04d608257eb999670d85261d5125d93 Author: Jan Palus Date: Tue Jun 7 11:39:01 2022 bring back patch from rpm 4.16 for no exe bit when searching debuginfo; rel 2 which now considers non-executable object file matching pattern found in `find-debuginfo`: ^\(.*\):[ ]*.*ELF.*, not stripped.* Which in turn causes object file to be passed to `eu-strip` directly responsible for stripping .note.GNU-stack section. Fix proposals: 1. modify `find-debuginfo` pattern to include ELF.*\(executable\|shared object\) 2. modify macros to invoke `find-debuginfo` with `--keep-section .note.GNU-stack` 3. both 1 and 2 Comments welcome. ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
glibc 2.36 *.o files debug extraction broken
In glibc 2.36 build debuginfo extraction process removes .note.GNU-stack section: (before installing) $ objdump -h ../BUILD/glibc-2.36.debuginfo/builddir/csu/crtn.o ../BUILD/glibc-2.36.debuginfo/builddir/csu/crtn.o: file format elf32-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 0034 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 0034 2**0 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0034 2**0 ALLOC 3 .note.gnu.property 0044 0034 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .init 0005 0078 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 5 .fini 0005 007d 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 6 .note.GNU-stack 0082 2**0 CONTENTS, READONLY 7 .debug_line 005a 0084 2**0 CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS 8 .debug_info 0022 00d9 2**0 CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS 9 .debug_abbrev 0012 00fb 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 10 .debug_aranges 0028 0110 2**3 CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS 11 .debug_str004f 0133 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 12 .debug_ranges 0020 0184 2**3 CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS (after) /home/users/qboosh/tmp/glibc-2.36-i686-root-qboosh.debuginfo/usr/lib/crtn.o: file format elf32-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 0034 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 0034 2**0 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0034 2**0 ALLOC 3 .note.gnu.property 0044 0034 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .init 0005 0078 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 5 .fini 0005 007d 2**0 CONTENTS, ALLOC, LOAD, READONLY, CODE 6 .gnu_debuglink 0020 0084 2**2 CONTENTS, READONLY With debuginfo packages disabled, .note.GNU-stack section is still present. It results in binaries executable stack and linker features misdetection due to new warning: /usr/bin/ld: warning: /usr/lib/gcc/i686-pld-linux/11.3.0/../../../crtn.o: missing .note.GNU-stack section implies executable stack /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker affecting e.g. gjs: Compiler for C++ supports link arguments -Bsymbolic-functions: NO meson.build:78:12: ERROR: Problem encountered: -Bsymbolic-functions not supported, configure with -Dbsymbolic_functions=false or gcab: Compiler for C supports link arguments -Wl,-z,relro: NO Compiler for C supports link arguments -Wl,-z,now: NO + missing symbol versioning For now only i686 builds are affected because x86_64 and x32 glibc-devel packages haven't been updated on builders. Any guesses what changed? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
