[Bug libelf/23916] [bisected] elifutils-0.175 broke kernel's objtool (elifutils-0.173 works)

[slyfox at inbox dot ru]

https://sourceware.org/bugzilla/show_bug.cgi?id=23916

--- Comment #3 from Sergei Trofimovich  ---
Oh, interesting!

On a related note: should eu-elflint complain on originally compiled
rapl.o.back (from tarball)? That would ease detecting non-conformant binutils
versions.

Today no warnings are issued:

  $ eu-elflint rapl.o rapl.o.back 

  rapl.o:
  No errors

  rapl.o.back:
  No errors

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug binutils/23919] New: bfd doesn't handle ELF compressed data alignment

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23919

Bug ID: 23919
   Summary: bfd doesn't handle ELF compressed data alignment
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: mark at klomp dot org
CC: devurandom at gmx dot net, elfutils-devel at sourceware dot 
org,
mark at klomp dot org, slyfox at inbox dot ru,
unassigned at sourceware dot org
Depends on: 23916
  Target Milestone: ---

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

The ELF compression header has a field (ch_addralign) that is set to the
alignment of the uncompressed section. This way the section itself can have a
different alignment than the decompressed section. bfd (and readelf) however
explicitly make the section sh_addralign and ch_addralign equal. It also always
sets the alignment to 1 which is wrong when using a Elf32_Chdr (which has
alignment of 4) or Elf64_Chdr (which has alignment of 8).

This shows up with tools that use elfutils libelf which sets up the alignment
correctly.

First gas creates a compressed section with on alignment of 1.
Second libelf accepts this, but corrects the alignment when it
writes out the section.
Third bfd_check_compression_header sanity checks the section alignment,
but it checks that the compressed and decompressed alignment is equal?!?
I think it wanted to check that the alignment is a power of 2 instead.


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=23916
[Bug 23916] [bisected] elifutils-0.175 broke kernel's objtool (elifutils-0.173
works)
-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libelf/23916] [bisected] elifutils-0.175 broke kernel's objtool (elifutils-0.173 works)

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23916

Mark Wielaard  changed:

   What|Removed |Added

 Blocks||23919


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=23919
[Bug 23919] bfd doesn't handle ELF compressed data alignment
-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug binutils/23919] bfd doesn't handle ELF compressed data alignment

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23919

--- Comment #1 from Mark Wielaard  ---
Created attachment 11413
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11413&action=edit
Proposed patch to handle compressed section alignment correctly

The attached git format-patch resolved this issue by handling the
(de)compressed section alignment correctly.

-- 
You are receiving this mail because:
You are on the CC list for the bug.