[Bug libelf/23911] Typo in Copyright File
https://sourceware.org/bugzilla/show_bug.cgi?id=23911 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #1 from Mark Wielaard --- I cannot find this in the elfutils sources. I think this must be in the distro (Debian) copyright file. Could you check you are running Debian and file the bug against the Debian elfutils package? https://www.debian.org/Bugs/Reporting -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/23911] Typo in Copyright File
https://sourceware.org/bugzilla/show_bug.cgi?id=23911 --- Comment #2 from Martin Vrba --- (In reply to Mark Wielaard from comment #1) > I cannot find this in the elfutils sources. > > I think this must be in the distro (Debian) copyright file. Could you check > you are running Debian and file the bug against the Debian elfutils package? > > https://www.debian.org/Bugs/Reporting Hi Mark, you are right. I filed a bug to Debian... Thank you. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/23911] Typo in Copyright File
https://sourceware.org/bugzilla/show_bug.cgi?id=23911 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED URL||https://bugs.debian.org/cgi ||-bin/bugreport.cgi?bug=9144 ||14 Resolution|--- |MOVED --- Comment #3 from Mark Wielaard --- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914414 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug backends/23902] varlocs dwarf_cfi_addrframe: unknown error
https://sourceware.org/bugzilla/show_bug.cgi?id=23902 --- Comment #3 from Mark Wielaard --- (In reply to Kurt Roeckx from comment #2) > At least on mips I'm seeing an .eh_frame and .eh_frame_hdr section. It also > has some mips specific sections. Assuming they have "normal" types then that part should work because it is (mostly, except for register mapping) arch independent. > But note that various of the other tests say "Unwinding not supported for > this architecture". Is this just a test that also should get skipped? If it would return that error maybe. But the varlocs test doesn't rely on unwinding. There is something odd going on because it gives "Unknown Error", which is not explicitly set anywhere in the code, but is generated when __libelf_seterrno () is called with an unknown error code (which itself is a bug). So something doubly odd is going on. > PS: All arches except amd64 have "Unwinding not supported for this > architecture" in run-backtrace-data.sh, which I find a bit surprising. Yes, that is surprising, run-backtrace-data.sh really should just say that it is only supported on x86_64/amd64. Currently it "abuses" the "Unwinding not supported for this architecture" message to get a SKIP on any other arch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/23903] Uses linux specifc mremap
https://sourceware.org/bugzilla/show_bug.cgi?id=23903 --- Comment #4 from Mark Wielaard --- Having an msync that doesn't write out changes to a file is bad, but you might get away with it in most cases (the changes should be written to disk when munmap is called). You do need a mremap function, even if it always fails. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/23914] New: Add --disable-werror to ./configure support (example trigger: CFLAGS=-Og
https://sourceware.org/bugzilla/show_bug.cgi?id=23914 Bug ID: 23914 Summary: Add --disable-werror to ./configure support (example trigger: CFLAGS=-Og Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: general Assignee: unassigned at sourceware dot org Reporter: slyfox at inbox dot ru CC: elfutils-devel at sourceware dot org Target Milestone: --- Initially I attempted to reproduce https://bugs.gentoo.org/671650 on vanilla master on elfutils as: $ autoreconf -i -f && ./configure --disable-maintainer-mode CFLAGS=-Og && make && make check The problem is in unconditional -Werror addition in config/eu.am: $(if $($(*F)_no_Werror),,-Werror) \ May I ask to add --disable-werror support to ./configure? That way elfutils will be less dependent on exact toolchain version and compiler flags (specifically warning flags). Example failure: dwarf_child.c: In function '__libdw_find_attr': dwarf_child.c:99:10: error: 'readp' may be used uninitialized in this function [-Werror=maybe-uninitialized] readp += len; ^~ Today Gentoo crudely works it around by sed'ing out -Werror at build time: https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/elfutils/elfutils-0.175.ebuild#n34 sed -i 's:-Werror::' */Makefile.in || die Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/23903] Uses linux specifc mremap
https://sourceware.org/bugzilla/show_bug.cgi?id=23903 --- Comment #5 from Kurt Roeckx --- Since I don't have it, it will make this a Linux only package. This at least means that currently glib2.0 and rpm will also not be able to get build on non-Linux platforms. This is really a Linux specific system call. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug backends/23902] varlocs dwarf_cfi_addrframe: unknown error
https://sourceware.org/bugzilla/show_bug.cgi?id=23902 --- Comment #4 from Kurt Roeckx --- The varlocs test is calling dwarf_errmsg (-1) -- You are receiving this mail because: You are on the CC list for the bug.
[PATCH] libdw: Enable building with -Og.
When building with -Og gcc is unable to see that __libdw_dieabbrev ()
will initialize what the second argument points to when no error occurs
as called by dwarf_child and dwarf_getattrs. Causing an possibly
uninitialized error. Just initialize readp/die_addr to NULL, which is
the value we would return if an error occurs anyway.
https://sourceware.org/bugzilla/show_bug.cgi?id=23914
Signed-off-by: Mark Wielaard
---
libdw/ChangeLog| 5 +
libdw/dwarf_child.c| 2 +-
libdw/dwarf_getattrs.c | 2 +-
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/libdw/ChangeLog b/libdw/ChangeLog
index 7caa223..44405d7 100644
--- a/libdw/ChangeLog
+++ b/libdw/ChangeLog
@@ -1,3 +1,8 @@
+2018-10-23 Mark Wielaard
+
+ * dwarf_child.c (__libdw_find_attr): Initialize readp to NULL.
+ * dwarf_getattrs.c (dwarf_getattrs): Initialize die_addr to NULL.
+
2018-10-20 Mark Wielaard
* libdw.map (ELFUTILS_0.175): New section. Add dwelf_elf_begin.
diff --git a/libdw/dwarf_child.c b/libdw/dwarf_child.c
index 9446b88..2e39d83 100644
--- a/libdw/dwarf_child.c
+++ b/libdw/dwarf_child.c
@@ -43,7 +43,7 @@ internal_function
__libdw_find_attr (Dwarf_Die *die, unsigned int search_name,
unsigned int *codep, unsigned int *formp)
{
- const unsigned char *readp;
+ const unsigned char *readp = NULL;
/* Find the abbreviation entry. */
Dwarf_Abbrev *abbrevp = __libdw_dieabbrev (die, &readp);
diff --git a/libdw/dwarf_getattrs.c b/libdw/dwarf_getattrs.c
index 50faf98..4ac16b1 100644
--- a/libdw/dwarf_getattrs.c
+++ b/libdw/dwarf_getattrs.c
@@ -44,7 +44,7 @@ dwarf_getattrs (Dwarf_Die *die, int (*callback)
(Dwarf_Attribute *, void *),
if (unlikely (offset == 1))
return 1;
- const unsigned char *die_addr;
+ const unsigned char *die_addr = NULL;
/* Find the abbreviation entry. */
Dwarf_Abbrev *abbrevp = __libdw_dieabbrev (die, &die_addr);
--
1.8.3.1
[PATCH] libdwfl: Fix relocation overlap sanity check.
We would not relocate when the relocation section data or the target
section date would overlap with one of the ELF headers. This is only
really necessary if the data comes directly from the mmapped file.
Otherwise there is no real overlap and the relocations can be safely
applied.
One particular thing we got wrong with the original sanity check was
when the relocation data or target data section was compressed. In
that case it could happen we overestimated the size (because the Shdr
would have been updated to show the uncompressed data size). But
uncompressed data is always malloced and so cannot overlap with the
mmapped Elf header structures.
When building with CFLAGS="-g -Og" this showed up as a failure in
run-strip-reloc.sh for strip-compressed.o. Where the .debug_loc
section decompressed would "overlap" with the shdrs at the end of
the file and so wouldn't get relocations applied.
Signed-off-by: Mark Wielaard
---
The diff might look big, but without the whitespace changes it is just:
@@ -561,7 +562,13 @@ relocate_section (Dwfl_Module *mod, Elf *relocated, const
GElf_Ehdr *ehdr,
shdrs or phdrs data then we refuse to do the relocations. It
isn't illegal for ELF section data to overlap the header data,
but updating the (relocation) data might corrupt the in-memory
- libelf headers causing strange corruptions or errors. */
+ libelf headers causing strange corruptions or errors.
+
+ This is only an issue if the ELF is mmapped and the section data
+ comes from the mmapped region (is not malloced or decompressed).
+ */
+ if (relocated->map_address != NULL)
+{
size_t ehsize = gelf_fsize (relocated, ELF_T_EHDR, 1, EV_CURRENT);
if (unlikely (shdr->sh_offset < ehsize
|| tshdr->sh_offset < ehsize))
@@ -574,10 +581,14 @@ relocate_section (Dwfl_Module *mod, Elf *relocated, const
GElf_Ehdr *ehdr,
/* Overflows will have been checked by elf_getshdrnum/get|rawdata. */
size_t shentsize = gelf_fsize (relocated, ELF_T_SHDR, 1, EV_CURRENT);
GElf_Off shdrs_end = shdrs_start + shnums * shentsize;
- if (unlikely ((shdrs_start < shdr->sh_offset + shdr->sh_size
-&& shdr->sh_offset < shdrs_end)
- || (shdrs_start < tshdr->sh_offset + tshdr->sh_size
- && tshdr->sh_offset < shdrs_end)))
+ if (unlikely (shdrs_start < shdr->sh_offset + shdr->sh_size
+ && shdr->sh_offset < shdrs_end))
+ if ((scn->flags & ELF_F_MALLOCED) == 0)
+ return DWFL_E_BADELF;
+
+ if (unlikely (shdrs_start < tshdr->sh_offset + tshdr->sh_size
+ && tshdr->sh_offset < shdrs_end))
+ if ((tscn->flags & ELF_F_MALLOCED) == 0)
return DWFL_E_BADELF;
GElf_Off phdrs_start = ehdr->e_phoff;
@@ -589,11 +600,16 @@ relocate_section (Dwfl_Module *mod, Elf *relocated, const
GElf_Ehdr *ehdr,
/* Overflows will have been checked by elf_getphdrnum/get|rawdata. */
size_t phentsize = gelf_fsize (relocated, ELF_T_PHDR, 1, EV_CURRENT);
GElf_Off phdrs_end = phdrs_start + phnums * phentsize;
- if (unlikely ((phdrs_start < shdr->sh_offset + shdr->sh_size
-&& shdr->sh_offset < phdrs_end)
- || (phdrs_start < tshdr->sh_offset + tshdr->sh_size
- && tshdr->sh_offset < phdrs_end)))
+ if (unlikely (phdrs_start < shdr->sh_offset + shdr->sh_size
+ && shdr->sh_offset < phdrs_end))
+ if ((scn->flags & ELF_F_MALLOCED) == 0)
return DWFL_E_BADELF;
+
+ if (unlikely (phdrs_start < tshdr->sh_offset + tshdr->sh_size
+ && tshdr->sh_offset < phdrs_end))
+ if ((tscn->flags & ELF_F_MALLOCED) == 0)
+ return DWFL_E_BADELF;
+ }
}
/* Fetch the relocation section and apply each reloc in it. */
---
libdwfl/ChangeLog | 5
libdwfl/relocate.c | 80 --
2 files changed, 53 insertions(+), 32 deletions(-)
diff --git a/libdwfl/ChangeLog b/libdwfl/ChangeLog
index 45cc1b4..b96cebf 100644
--- a/libdwfl/ChangeLog
+++ b/libdwfl/ChangeLog
@@ -1,3 +1,8 @@
+2018-10-23 Mark Wielaard
+
+ * relocate.c (relocate_section): Only sanity check mmapped Elf files
+ for overlap. Don't error when section data was malloced, not mmapped.
+
2018-10-20 Mark Wielaard
* libdwflP.h (__libdw_open_elf): New internal function declaration.
diff --git a/libdwfl/relocate.c b/libdwfl/relocate.c
index 58c5678..88b5211 100644
--- a/libdwfl/relocate.c
+++ b/libdwfl/relocate.c
@@ -1,5 +1,5 @@
/* Relocate debug information.
- Copyright (C) 2005-2011, 2014, 2016 Red Hat, Inc.
+ Copyright (C) 2005-2011, 2014, 2016, 2018 Red Hat, Inc.
This file is part of elfutils.
This file is free software; you can redistribute it and/or modify
@@ -30,6 +30,7 @@
# include
#endif
+#include "libelfP.h"
#include "libdwflP.h
[Bug general/23914] Add --disable-werror to ./configure support (example trigger: CFLAGS=-Og
https://sourceware.org/bugzilla/show_bug.cgi?id=23914 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #1 from Mark Wielaard --- I rather have that people report such issues and we fix them. In this case it really was just that one gcc warning (plus an almost identical one in dwarf_getattrs): https://sourceware.org/ml/elfutils-devel/2018-q4/msg00174.html And that build flag actually showed a very interesting nasty bug that we might not have found otherwise: https://sourceware.org/ml/elfutils-devel/2018-q4/msg00175.html Does Gentoo show any other compile errors? BTW for make check to work correctly you do of course need debuginfo, so you really need CLAGS="-g -Og". -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/23903] Uses linux specifc mremap
https://sourceware.org/bugzilla/show_bug.cgi?id=23903 --- Comment #6 from Mark Wielaard --- It is fine for elfutils to have GNU/Linux specific code since that is the primary target. But if other platforms provide needed functionality in a different way then patches are obviously more than welcome. In the case of mremap you could even get away with something that always fails. Which would probably work just fine for Hurd, but for kfreebsd you really need to figure out first why it seems to provide a mremap function but then fails while linking. Otherwise it will be hard to know when/why to provide an alternative. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug backends/23902] varlocs dwarf_cfi_addrframe: unknown error
https://sourceware.org/bugzilla/show_bug.cgi?id=23902 --- Comment #5 from Mark Wielaard --- (In reply to Kurt Roeckx from comment #4) > The varlocs test is calling dwarf_errmsg (-1) OK, that will show the last libdw error set on the current thread. In which case we might actually have a candidate for why it was set. The only place DWARF_E_UNKNOWN_ERROR is set (returned) is: libdw/cfi.c (cie_cache_initial_state): /* Fetch the ABI's default CFI program. */ if (likely (cache->ebl != (void *) -1l) && unlikely (ebl_abi_cfi (cache->ebl, &abi_info) < 0)) return DWARF_E_UNKNOWN_ERROR; That would explain the issue on alpha at least because that doesn't have a backend hook for abi_cfi. I suspect your mips and hppa backends also don't have that hooked. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug backends/23902] varlocs dwarf_cfi_addrframe: unknown error
https://sourceware.org/bugzilla/show_bug.cgi?id=23902 --- Comment #6 from Kurt Roeckx --- Yes, they all 3 seem to be missing that callback. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/23903] Uses linux specifc mremap
https://sourceware.org/bugzilla/show_bug.cgi?id=23903 --- Comment #7 from Kurt Roeckx --- I've filed a bug in Debian about mremap() being in the headers, so that should hopefully get fixed. But that will not fix the problem, it will either now just generate a warning that it doesn't have a prototype, or give a compilation error. It seems to me that we want to detect in configure that mremap() exists, and if it doesn't disable the use of mmap. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug general/23914] Add --disable-werror to ./configure support (example trigger: CFLAGS=-Og
https://sourceware.org/bugzilla/show_bug.cgi?id=23914 --- Comment #2 from Sergei Trofimovich --- (In reply to Mark Wielaard from comment #1) > I rather have that people report such issues and we fix them. Totally understandable. My intent is to only still be able to build old releases with new toolchains or against exotic yet safe CFLAGS without resort to manual patching of build system. I would suggest having --enable-werror enabled by default. That way we would be able to disable it downstream for older packages on first offense. > In this case it really was just that one gcc warning (plus an almost > identical one in dwarf_getattrs): > https://sourceware.org/ml/elfutils-devel/2018-q4/msg00174.html > > And that build flag actually showed a very interesting nasty bug that we > might not have found otherwise: > https://sourceware.org/ml/elfutils-devel/2018-q4/msg00175.html > > Does Gentoo show any other compile errors? Yes. I can trigger a lot of them passing various warning flags (I'll post those below). Gentoo allows users to control CC and CFLAGS and thus the space for getting a warning is wide. People frequently use things like -Wcast-qual or other high signal-to-noise flags for their purposes. My favourite example is ./configure CFLAGS="-g -Wall" # works today without failures or even ./configure CC=clang CFLAGS="-g -Weverything" but elfutils does not seem to support clang. Real-world examples used by people: 1. CFLAGS="-g -Wall -Wcast-qual" In file included from gelf_xlate.c:166: version_xlate.h: In function 'elf_cvt_Verdef': version_xlate.h:74:31: error: cast discards 'const' qualifier from pointer target type [-Werror=cast-qual] dsrc = (GElf_Verdef *) ((char *) src + def_offset); ^ 2. CFLAGS="-g -O2 -Wstack-protector" CC readelf.o readelf.c: In function 'open_input_section': readelf.c:581:1: error: stack protector not protecting local variables: variable length buffer [-Werror=stack-protector] open_input_section (int fd) ^~ > BTW for make check to work correctly you do of course need debuginfo, so you > really need CLAGS="-g -Og". Yes, sorry. Forgot about the unconditional -g passing (we do it all the time). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libelf/23916] New: [bisected] elifutils-0.175 broke kernel's objtool (elifutils-0.173 works)
https://sourceware.org/bugzilla/show_bug.cgi?id=23916
Bug ID: 23916
Summary: [bisected] elifutils-0.175 broke kernel's objtool
(elifutils-0.173 works)
Product: elfutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libelf
Assignee: unassigned at sourceware dot org
Reporter: slyfox at inbox dot ru
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
Created attachment 11411
--> https://sourceware.org/bugzilla/attachment.cgi?id=11411&action=edit
b.tar.gz
Looks like libelf started adding larger alignment to .debug sections but
something went wrong. Original report: https://bugs.gentoo.org/671760
The symptom: kernel can't be compiled on amd64 against elifutils-0.175:
linux.git $ LANG=C make arch/x86/events/intel/intel-rapl-perf.ko
LD [M] arch/x86/events/intel/intel-rapl-perf.o
ld: arch/x86/events/intel/rapl.o: unable to initialize decompress status
for section .debug_info
arch/x86/events/intel/rapl.o: file not recognized: file format not
recognized
Minimal reproducer (against kernel's objtool):
$ cat rapl.c.c
void a(void) {}
$ gcc -nostdinc -g -o rapl.o -c rapl.c.c
$ ./objtool orc generate --module --no-fp --retpoline rapl.o
$ ld -m elf_x86_64 -z max-page-size=0x20 -r -o intel-rapl-perf.o rapl.o
ld: rapl.o: unable to initialize decompress status for section .debug_info
...
rapl.o: file not recognized: file format not recognized
Bisected down to something plausible:
$ git bisect bad
cf10453f8252df81225796d98548ba6eac113df3 is the first bad commit
commit cf10453f8252df81225796d98548ba6eac113df3
Author: Mark Wielaard
Date: Tue Nov 13 21:18:09 2018 +0100
libelf: Correctly setup alignment of SHF_COMPRESSED section data.
We didn't set the alignment of SHF_COMPRESSED sections correctly.
Those sections start with an Elf(32|64)_Chdr. Make sure sh_addralign
is setup to be able to read such a struct directly. Likewise don't
trust the alignment set on any SHF_COMPRESSED section, but always
make the (raw) compressed data aligned correctly for the reading the
Elf(32|64)_Chdr directly.
Signed-off-by: Mark Wielaard
:04 04 99b0262c62d71ac5aaa178519df9a4db917ab1bd
df8299442f6fae9677d31699b88638a325eb9527 M libelf
$ git bisect log
# bad: [628b4a93c6863b9982d817db6acaacbc4e116453] tests: Call test_cleanup in
backtrace-subr.sh check_unsupported.
# good: [aa36de0335e3ce12898954985a208f6336731289] Prepare for 0.173
git bisect start 'master' 'elfutils-0.173'
# good: [2876b3b648f665736ac9c879d34de5e3866ba8f9] Handle ADD/SUB relocations
git bisect good 2876b3b648f665736ac9c879d34de5e3866ba8f9
# good: [f2d59180b90b56b32240f0ba106add050a1b7d09] strip: Extract code to
update shdrstrndx into new common function.
git bisect good f2d59180b90b56b32240f0ba106add050a1b7d09
# good: [d3e6266754b95244063aa1e40c531fdd57259332] strip: Also handle gnu
compressed debug sections with --reloc-debug-sections
git bisect good d3e6266754b95244063aa1e40c531fdd57259332
# good: [d3e6266754b95244063aa1e40c531fdd57259332] strip: Also handle gnu
compressed debug sections with --reloc-debug-sections
git bisect good d3e6266754b95244063aa1e40c531fdd57259332
# bad: [a01938d584b91e747167bb4b3f30ec300c4d6e43] libelf: Mark both fsize and
msize with const attribute.
git bisect bad a01938d584b91e747167bb4b3f30ec300c4d6e43
# bad: [a01938d584b91e747167bb4b3f30ec300c4d6e43] libelf: Mark both fsize and
msize with const attribute.
git bisect bad a01938d584b91e747167bb4b3f30ec300c4d6e43
# bad: [22ec8efc1dd87cdc7892523457eb55990b967224] elflint: Allow
PT_GNU_EH_FRAME segment to match SHT_X86_64_UNWIND section.
git bisect bad 22ec8efc1dd87cdc7892523457eb55990b967224
# bad: [cf10453f8252df81225796d98548ba6eac113df3] libelf: Correctly setup
alignment of SHF_COMPRESSED section data.
git bisect bad cf10453f8252df81225796d98548ba6eac113df3
# first bad commit: [cf10453f8252df81225796d98548ba6eac113df3] libelf:
Correctly setup alignment of SHF_COMPRESSED section data.
--
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)
https://sourceware.org/bugzilla/show_bug.cgi?id=23916 --- Comment #1 from Sergei Trofimovich --- objtool is a part of linux kernel: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/objtool Attached b.tar.gz contains: - objtool binary - object files before and after mangling with objtool Note the .debug_info offset and alignment change: $ readelf -a rapl.o.back > pre $ readelf -a rapl.o > post $ diff -U 0 pre post - [ 4] .debug_info PROGBITS 0047 - 003c C 0 0 1 + [ 4] .debug_info PROGBITS 0048 + 003c C 0 0 8 My wild guess is that section's start is not adjusted correctly. -- 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)
https://sourceware.org/bugzilla/show_bug.cgi?id=23916
--- Comment #2 from Mark Wielaard ---
Thanks. I am fairly sure this is a bug in binutils/bfd.
First gas creates a compressed section with the wrong alignment.
Because a compressed section has a Chdr it needs to be aligned
to either 4 or 8 depending on ELF class (32 or 64 bit). The actual
alignment of the uncompressed section data is contained in the Chdr
as ch_addralign. gas/bfd seems to always just use the same (1) alignment
for both the uncompressed section data and compressed data.
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.
The following (obviously somewhat incorrect, because it just ignores the
alignment completely) patch seems to fix/workaround things:
diff --git a/bfd/bfd.c b/bfd/bfd.c
index 15becd7ae8..9cc05a0174 100644
--- a/bfd/bfd.c
+++ b/bfd/bfd.c
@@ -2404,7 +2404,7 @@ bfd_check_compression_header (bfd *abfd, bfd_byte
*contents,
chdr.ch_addralign = bfd_get_64 (abfd, &echdr->ch_addralign);
}
if (chdr.ch_type == ELFCOMPRESS_ZLIB
- && chdr.ch_addralign == 1U << sec->alignment_power)
+ /* && chdr.ch_addralign == 1U << sec->alignment_power */)
{
*uncompressed_size = chdr.ch_size;
return TRUE;
I'll file a proper bug and patch tomorrow against binutils.
--
You are receiving this mail because:
You are on the CC list for the bug.
