Re: [PATCH] Recognize NT_VERSION notes.
On Mon, 2018-11-12 at 00:08 +0100, Mark Wielaard wrote: > NT_VERSION notes are emitted by the gas .version directive. > They have an empty description and (ab)use the owner name to store > the version data string. I pushed this to master because it is a prerequisite of the GNU Build Attribute ELF Notes patch.
Re: [PATCH] Handle GNU Build Attribute ELF Notes.
On Tue, 2018-11-13 at 11:56 +, Nick Clifton wrote: > + /* There might or might not be a pair of addresses in the desc. */ > > FYI - There was an old version of the Watermark specification that only put > one address into the note's desc field. This version was never used in > production binaries, so it is unlikely that such notes will ever be found in > the wild. If it never happens in production binaries lets ignore this quirk. > Anyway although I am not an official elfutils reviewer the patch > looks great > to me. I hope that it will be accepted into the sources. Lets do that then :) It also resolves the self-test failure on Fedora 29, so it should make the buildbot happy again. Pushed to master. Thanks, Mark
Re: [PATCH] strip: Also handle gnu compressed debug sections with --reloc-debug-sections
On Fri, 2018-11-09 at 17:41 +0100, Mark Wielaard wrote: > Check whether a section was gnu compressed and decompress it first > before trying to resolve relocations. Recompress it afterwards. > > This found a bug in elf_compress_gnu which would use the "raw" file > contents even if the user had just created the section (copying over > the section from the original input file). > > Add compressed ET_REL tests to run-strip-reloc.sh testcase. Pushed this to master.
Buildbot failure in Wildebeest Builder on whole buildset
The Buildbot has detected a failed build on builder whole buildset while building elfutils. Full details are available at: https://builder.wildebeest.org/buildbot/#builders/3/builds/299 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-x86_64 Build Reason: Blamelist: Mark Wielaard BUILD FAILED: failed test (failure) Sincerely, -The Buildbot
Re: Buildbot failure in Wildebeest Builder on whole buildset
On Tue, 2018-11-13 at 16:42 +, build...@builder.wildebeest.org wrote: > The Buildbot has detected a failed build on builder whole buildset > while building elfutils. > Full details are available at: > https://builder.wildebeest.org/buildbot/#builders/3/builds/299 This is disappointing. You fix one bug and find another :) The issue here is (when running the testsuite under gcc undefinedness sanitizer): runtest testfile-debug-rel-ppc64-z.o ../../../libelf/gelf_xlate.h:53:1: runtime error: member access within misaligned address 0x0402928d for type 'struct Elf64_Chdr', which requires 8 byte alignment 0x0402928d: note: pointer points here 1d bb 0a c3 01 00 00 00 00 00 00 00 71 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 78 9c 63 60 ^ *** failure strip testfile-debug-rel-ppc64-z.o ../../../libelf/gelf_xlate.h:53:1: runtime error: member access within misaligned address 0x04029175 for type 'struct Elf64_Chdr', which requires 8 byte alignment 0x04029175: note: pointer points here 1d bb 0a c3 01 00 00 00 00 00 00 00 71 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 78 9c 63 60 ^ *** failure strip --reloc-debug-sections testfile-debug-rel-ppc64-z.o This happens when writing out the file to disk. The section is compressed, and we try to write it back to disk, for this we need to translate the on disk Elf_Chdr (because it is a big endian ELF file and the memory representation on x86_64 is little endian): #1 0x77f8ad98 in Elf64_cvt_Chdr (encode=, len=, src=, dest=) at gelf_xlate.h:37 #2 Elf64_cvt_chdr (dest=, src=0x439380, len=69, encode=) at chdr_xlate.h:32 #3 0x77f9fd96 in __elf64_updatemmap (elf=elf@entry=0x4377c0, change_bo=change_bo@entry=1, shnum=shnum@entry=22) at elf32_updatefile.c:368 #4 0x77f98a3d in write_file (shnum=22, change_bo=1, size=2872, elf=0x4377c0) at elf_update.c:121 #5 elf_update (elf=0x4377c0, cmd=cmd@entry=ELF_C_WRITE) at elf_update.c:231 #6 0x0040bd29 in handle_elf (fd=3, elf=, mode=436, tvp=0x0, prefix=0x0) at strip.c:2448 #7 0x0040f4be in process_file ( fname=0x7fffdbab "testfile-debug-rel-ppc64-z.o") at strip.c:769 #8 0x00402bdf in main (argc=5, argv=0x7fffd848) at strip.c:265 The compressed sections however simply have an alignment of 1. I think this is really a bug in binutils gas which produced this particular testfile. But it looks like we make the same mistake (decompressing and recompressing with eu-elfcompress produces the same misaligned compressed section). So we might actually have two bugs. 1) we don't handle incorrectly aligned compressed sections and 2) we generate such incorrectly aligned compressed sections ourselves. Pondering fixes. Cheers, Mark
Re: Buildbot failure in Wildebeest Builder on whole buildset
On Tue, 2018-11-13 at 18:29 +0100, Mark Wielaard wrote:
> So we might actually have two bugs. 1) we don't handle incorrectly
> aligned compressed sections and 2) we generate such incorrectly
> aligned compressed sections ourselves.
>
> Pondering fixes.
The fixes were easy!
(Hopefully the buildbot agrees.)
I pushed the attached.
Cheers,
Mark
From cf10453f8252df81225796d98548ba6eac113df3 Mon Sep 17 00:00:00 2001
From: Mark Wielaard
Date: Tue, 13 Nov 2018 21:18:09 +0100
Subject: [PATCH] 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
---
libelf/ChangeLog | 7 +++
libelf/elf_compress.c | 4 ++--
libelf/elf_getdata.c | 10 --
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/libelf/ChangeLog b/libelf/ChangeLog
index ab078cb..93820d1 100644
--- a/libelf/ChangeLog
+++ b/libelf/ChangeLog
@@ -1,3 +1,10 @@
+2018-11-13 Mark Wielaard
+
+ * elf_getdata.c (__libelf_set_rawdata_wrlock): Explicitly set the
+ alignment of SHF_COMPRESSED data to the alignment of ELF_T_CHDR.
+ * elf_compress.c (elf_compress): After compression set sh_addralign
+ to the alignment of ELF_T_CHDR.
+
2018-11-09 Mark Wielaard
* elf_compress_gnu.c (elf_compress_gnu): Use elf_getdata.
diff --git a/libelf/elf_compress.c b/libelf/elf_compress.c
index d96245d..be9eeab 100644
--- a/libelf/elf_compress.c
+++ b/libelf/elf_compress.c
@@ -455,14 +455,14 @@ elf_compress (Elf_Scn *scn, int type, unsigned int flags)
{
Elf32_Shdr *shdr = elf32_getshdr (scn);
shdr->sh_size = new_size;
- shdr->sh_addralign = 1;
+ shdr->sh_addralign = __libelf_type_align (ELFCLASS32, ELF_T_CHDR);
shdr->sh_flags |= SHF_COMPRESSED;
}
else
{
Elf64_Shdr *shdr = elf64_getshdr (scn);
shdr->sh_size = new_size;
- shdr->sh_addralign = 1;
+ shdr->sh_addralign = __libelf_type_align (ELFCLASS64, ELF_T_CHDR);
shdr->sh_flags |= SHF_COMPRESSED;
}
diff --git a/libelf/elf_getdata.c b/libelf/elf_getdata.c
index 2043bba..639a798 100644
--- a/libelf/elf_getdata.c
+++ b/libelf/elf_getdata.c
@@ -268,9 +268,15 @@ __libelf_set_rawdata_wrlock (Elf_Scn *scn)
/* First a test whether the section is valid at all. */
size_t entsize;
- /* Compressed data has a header, but then compressed data. */
+ /* Compressed data has a header, but then compressed data.
+ Make sure to set the alignment of the header explicitly,
+ don't trust the file alignment for the section, it is
+ often wrong. */
if ((flags & SHF_COMPRESSED) != 0)
- entsize = 1;
+ {
+ entsize = 1;
+ align = __libelf_type_align (elf->class, ELF_T_CHDR);
+ }
else if (type == SHT_HASH)
{
GElf_Ehdr ehdr_mem;
--
1.8.3.1
Re: [PATCH] Also find CFI in sections of type SHT_X86_64_UNWIND
On Sun, 2018-11-11 at 00:28 +0100, Mark Wielaard wrote: > Found another issue while testing with a gcc 8.1 and gold setup I > noticed some self-tests failed because elflint doesn't know about > SHT_X86_64_UNWIND section type and cannot match the PT_GNU_EH_FRAME > segment. The attached patch fixes it. > Subject: [PATCH] elflint: Allow PT_GNU_EH_FRAME segment to match > SHT_X86_64_UNWIND section. > > The gold linker might generate an .eh_frame_hdr with a > SHT_X86_64_UNWIND type instead of a SHT_PROGBITS type. Pushed to master.
