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