+++ This bug was initially created as a clone of Bug #1303845 +++

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.

--- Additional comment from RHEL Product and Program Management on 2016-02-02 03:42:26 EST ---

This bugzilla has Keywords: Regression or TestBlocker.

Since no regressions or test blockers are allowed between releases,
it is also being [proposed|marked] as a blocker for this release.

Please resolve ASAP.

--- Additional comment from Mark Wielaard on 2016-02-02 04:29:43 EST ---

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.

--- Additional comment from Eryu Guan on 2016-02-02 05:41:57 EST ---

Still reproducible with --permissive option

[root@dhcp-66-86-3 xfstests]# eu-strip --permissive testprog
eu-strip: while writing 'testprog': invalid section alignment

--- Additional comment from Eryu Guan on 2016-02-02 05:42 EST ---



--- Additional comment from Eryu Guan on 2016-02-02 05:44:24 EST ---

And I was trying to build this src rpm

rpmbuild --rebuild xfstests-20160111-1.git.src.rpm

http://download.eng.pnq.redhat.com/qa/rhts/lookaside/xfstests/xfstests-20160111-1.git.src.rpm

--- Additional comment from Mark Wielaard on 2016-02-03 17:26:14 EST ---

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.

--- Additional comment from Mark Wielaard on 2016-02-04 04:04:32 EST ---

I posted a fix and new testcase upstream:
https://lists.fedorahosted.org/archives/list/elfutils-devel@lists.fedorahosted.org/message/OP6AXOW5PF6GPB4KN7XQZSZ5JY6RK52U/

--- Additional comment from errata-xmlrpc on 2016-02-04 11:23:00 EST ---

Bug report changed to ON_QA status by Errata System.
A QE request has been submitted for advisory RHEA-2015:21950-01
https://errata.devel.redhat.com/advisory/21950