Worked around by downgrading to elfutils-0.174-1.fc29.x86_64

That is surprising. There is indeed a binutils bug with compressed ELF debug sections https://sourceware.org/bugzilla/show_bug.cgi?id=23919 that gets triggered by a change in elfutils 0.175. But compressed debug sections are disabled by default on Fedora.

Is there a possibility that compressed ELF debug sections are turned on somehow?
Nick would it be possible to backport the patches for that bug to the f29 binutils package?

(In reply to Mark Wielaard from comment #3)

> Nick would it be possible to backport the patches for that bug to the f29
> binutils package?

On it....

The patches are in binutils-2.31.1-18.fc29.  I am updating rawhide now...

OK, the patches are now also in rawhide (binutils-2.31.1-23.fc30) and on the GNU Binutils 2.31 branch.

(In reply to Janusz Krzysztofik from comment #0)
> Version-Release number of selected component (if applicable):
> binutils-2.31.1-17.fc29.x86_64
> elfutils-0.176-1.fc29.x86_64
> 
> How reproducible:
> Attempt to build a kernel with CONFIG_DEBUG_INFO selected.
> 
> 
> Steps to Reproduce:
> 1. Enter a kernel source tree
> 2. Configure with CONFIG_DEBUG_INFO selected
> 3. Build with make
> 
> Actual results:
> arch/x86/kernel/head_64.o: unable to initialize decompress status for
> section .debug_line

I just tried a local kernel-4.20.10-200.fc29.x86_64 fedpkg build with binutils-2.31.1-17.fc29.x86_64 and elfutils-0.176-1.fc29.x86_64. That builds at least two kernel variants that both have CONFIG_DEBUG_INFO set. But cannot replicate this issue.

Could you give more precise instructions how to replicate your failure? Just building the kernel rpm package seems to work just fine.

(In reply to Nick Clifton from comment #4)
> (In reply to Mark Wielaard from comment #3)
> 
> > Nick would it be possible to backport the patches for that bug to the f29
> > binutils package?
> 
> On it....

Thanks. Do note that gdb might also need an update because it uses its own copy of libbfd.
The old version might not be able to read the corrected compressed sections because the
old code had a bogus check in bfd.c (bfd_check_compression_header). The chdr.ch_addralign check.

Which changed:
 -         && chdr.ch_addralign == 1U << sec->alignment_power)
 +         && chdr.ch_addralign == (1U << bfd_log2 (chdr.ch_addralign)))

I think the new check handles both the correct chdr and the old (broken) one.
That assumes in the original (broken) case chdr.ch_addralign == sec->alignment_power == 1 (for .debug sections).

If that is wrong we might have to relax that check.

(In reply to Mark Wielaard from comment #7)
> (In reply to Janusz Krzysztofik from comment #0)
> > Version-Release number of selected component (if applicable):
> > binutils-2.31.1-17.fc29.x86_64
> > elfutils-0.176-1.fc29.x86_64
> > 
> > How reproducible:
> > Attempt to build a kernel with CONFIG_DEBUG_INFO selected.
> > 
> > 
> > Steps to Reproduce:
> > 1. Enter a kernel source tree
> > 2. Configure with CONFIG_DEBUG_INFO selected
> > 3. Build with make
> > 
> > Actual results:
> > arch/x86/kernel/head_64.o: unable to initialize decompress status for
> > section .debug_line
> 
> I just tried a local kernel-4.20.10-200.fc29.x86_64 fedpkg build with
> binutils-2.31.1-17.fc29.x86_64 and elfutils-0.176-1.fc29.x86_64. That builds
> at least two kernel variants that both have CONFIG_DEBUG_INFO set. But
> cannot replicate this issue.
> 
> Could you give more precise instructions how to replicate your failure? Just
> building the kernel rpm package seems to work just fine.

Hi,

That's not simple.  In my initial scenario, I was building a custom kernel under buildroot, using binutils 2.29.1 compiled under buildroot.  Surprisingly, the kernel build failure started to appear after elfutils RPMs had bin upgraded.  The same bug was still hitting me with buildroot compiled binutils 2.31.1.  I know my issue should be actually resolved by patching the binutils soruces I use rather than a Fedora provided package, however I still can't understand how upgrade of elfutils RPM could trigger that failure.

Since a simple redirection of 'ld' to the one provided by RPM package was giving me exactly the same error, I decided to notify you about possible issue with the package.

Using the same trick with 'ld' after I upgraded to binutils-2.31.1-1.18 has fixed the issue for me, so I think I was not wrong about that.

Thanks,
Janusz

Sorry, I had bintuils-2.31.1-18.fc29 on mind.
Janusz

(In reply to Janusz Krzysztofik from comment #9)
> That's not simple.  In my initial scenario, I was building a custom kernel
> under buildroot, using binutils 2.29.1 compiled under buildroot. 
> Surprisingly, the kernel build failure started to appear after elfutils RPMs
> had bin upgraded.  The same bug was still hitting me with buildroot compiled
> binutils 2.31.1.  I know my issue should be actually resolved by patching
> the binutils soruces I use rather than a Fedora provided package, however I
> still can't understand how upgrade of elfutils RPM could trigger that
> failure.

I think what happened is that you build your own binutils under buildroot
and somehow got compressed debug ELF sections enabled by default. Unless
you have the binutils fix that would have created ELF files which had wrong
alignment for the ELF section compression header. Starting with elfutils-0.175
libelf will correct the alignment such compressed ELF sections if it writes out
such files after modification (for example my eu-strip or any other tools,
like the kernel objtool). Unfortunately binutils/bfd also had a bug that checked
for the wrong alignment... And if the alignment of the compressed section header
and the uncompressed data didn't match up (which they normally wouldn't)
it would simply reject such files, giving the "unable to initialize decompress
status for section" message. 

You wouldn't have seen any of these issues with the Fedora binutils package because it explicitly makes sure not to create compressed debug ELF sections.

Has this issue been resolved now or are you still seeing it with the latest binutils and elfutils packages?

Hi,

Sorry for late answer, and for not being clear enough in my previous response.

As reported before, I was able to work around my issue using ld linker provided 
by binutils-2.31.1-1.18, hence I think we can assume the incompatibility between 
binutils and libelf has been fixed correctly with that version of binutils RPM.

For those interested in a long-term resolution of my issue who may be reading 
this, a proper fix was to configure buildroot to not use host provided libelf 
but build its own.

Thanks,
Janusz

Thanks for the feedback. Lets consider this issue closed now.