Hide Forgot
Created attachment 1120358 [details] test c program Description of problem: On RHEL6.8 compose, my test package failed to build from src rpm because of eu-strip reported "invalid section alignment" when stripping debuginfo from built binaries. extracting debug info from /root/rpmbuild/BUILDROOT/xfstests-20160111-1.git.x86_64/var/lib/xfstests/src/aio-dio-regress/aio-dio-subblock-eof-read eu-strip: while writing '/root/rpmbuild/BUILDROOT/xfstests-20160111-1.git.x86_64/usr/lib/debug/var/lib/xfstests/src/aio-dio-regress/aio-dio-subblock-eof-read.debug.9QEhnw': invalid section alignment error: Bad exit status from /var/tmp/rpm-tmp.D9kBkn (%install) It can be reproduced by compiling the C file by hand and call eu-strip. Version-Release number of selected component (if applicable): elfutils-0.164-1.el6.x86_64 gcc-4.4.7-17.el6.x86_64 kernel-2.6.32-606.el6.x86_64 How reproducible: always Steps to Reproduce: 1. compile attached c file: gcc -g aio-dio-subblock-eof-read.c -laio -o testprog 2. eu-strip testprog Actual results: [root@dhcp-66-86-3 xfstests]# eu-strip testprog eu-strip: while writing 'testprog': invalid section alignment Expected results: no error Additional info: The same package can be built on RHEL6.7 distrobution. And I'm not sure if this really is a elfutils issue, but that's where it fails.
Thanks for the report. I don't currently have a 6.8 setup. I will set one up. But could you attach the testprog binary too if it isn't too big? Could you also try eu-strip --permissive --permissive Relax a few rules to handle slightly broken ELF files I thought that the rpm build scripts used --permissive, but if I am wrong about that, or if the issue is also reproducible with --permissive then this is certainly a regression.
Still reproducible with --permissive option [root@dhcp-66-86-3 xfstests]# eu-strip --permissive testprog eu-strip: while writing 'testprog': invalid section alignment
Created attachment 1120373 [details] testprog binary file
Looks like this regression was introduced by me in elfutils-0.162 (RHEL 6.7 has 0.161). Note the last part between ==> and <== commit c0748eff8473b0caa6d51812aa31349bf1dce042 Author: Mark Wielaard <mjw> Date: Tue May 12 15:28:06 2015 +0200 libelf: More checking of valid sh_addralign values. There were two issues with bogus sh_addralign values. First we would only check the individual Elf_Data d_align values were powerof2. But not the actual shdr addralign value. This would cause an issue if the shdr addralign was bigger than all of the individual d_align values. Then we could write out a bogus (! powerof2) shdr addralign value for the sections. Secondly when reading in the Elf_Data we would set the d_align value to the value of the shdr addralign value. But we would not check it was valid at all. In practice there are ELF files with incorrect sh_addralign values (they are a powerof2, but aren't aligned to the ELF image offset). We would try to fix that up in elf_update by adding extra padding. But this could bloat the ELF image a lot for large alignment values. So for too large alignments that are bigger than the offset in the ELF file clamp them to the offset value. ==> This could lead us to reject to write out the data again when the offset was not a powerof2. But this will only happen for aligment values bigger than 64. Which are uncommon in practice. <== Signed-off-by: Mark Wielaard <mjw> Which triggers for this sections: [25] .bss NOBITS 0000000000601000 00000fd4 00002000 0 WA 0 0 4096 Alignment is 4096, but offset in the file is 4052 (0x0fd4). So the d_align gets clamped at 4052. Which then gets rejected when writing this section out again because that isn't a power of 2.
I posted a fix and new testcase upstream: https://lists.fedorahosted.org/archives/list/elfutils-devel@lists.fedorahosted.org/message/OP6AXOW5PF6GPB4KN7XQZSZ5JY6RK52U/
My test pakcage builds without problems now, thanks a lot!
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-0772.html