Re: [PATCH v2] Support building when fts and obstack aren't part of libc.
On Tue, 2020-11-03 at 20:39 -0300, Érico Nogueira via Elfutils-devel wrote: > On Tue Nov 3, 2020 at 10:33 PM -03, Dmitry V. Levin wrote: > > On Sun, Nov 01, 2020 at 09:48:50PM -0300, Érico Nogueira via > > Elfutils-devel wrote: > > > > > > +saved_LIBS="$LIBS" > > > +AC_SEARCH_LIBS([_obstack_free], [obstack]) > > > +LIBS="$saved_LIBS" > > > +case "$ac_cv_search__obstack_free" in > > > +no) AC_MSG_FAILURE([failed to find obstack_free]) ;; > > > +-l*) obstack_LIBS="$ac_cv_search__obstack_free" ;; > > > +*) obstack_LIBS= ;; > > > +esac > > > +AC_SUBST([obstack_LIBS]) > > > + > > > > Hmm. In [1] I suggested to check for obstack_free, but > > here I see you're checking for _obstack_free instead. > > Since both symbols are provided by glibc, I wonder what was > > the reason for this change. Is it something to do with libobstack? > > I'm using the version of libobstack [1] that as far as I know is used by > most musl-based distros (some of them pull directly from pullmoll's > personal repo rather than from the void-linux namespace). > > As you can see in [2], obstack_free is a macro, and AC_SEARCH_LIBS > didn't seem able to find it during my testing. On the other hand, > _obstack_free was an actual function, so I switched to it. > > > > > By the way, the text of AC_MSG_FAILURE is out of sync with the symbol > > name. > > Indeed. I can send a fix for it together with the argp patch if that's > ok. Thanks for noticing. It does look like all (exported) obstack symbols start with _obstack (although there also is an non-underscore alias obstack_free in glibc). So checking for _obstack_free seems correct. If you could sent a patch (together with the argp check cleanup) to make the failure message to also mention the underscore that would be great. Thanks, Mark
Re: [PATCH] debuginfod-find: Be a bit less verbose with -v
On Wed, 2020-11-11 at 22:24 +0100, Mark Wielaard wrote: > On Wed, 2020-11-11 at 15:57 -0500, Frank Ch. Eigler wrote: > > On Wed, Nov 11, 2020 at 09:31:38PM +0100, Mark Wielaard wrote: > > > debuginfod-find -v enables a progressfn that prints the Progress > > > every > > > time the callback is called. [...] > > > [...] > > > - fprintf (stderr, "Progress %ld / %ld\n", a, b); > > > [...] > > > > Another option is to use something close what the builtin env > > DEBUGINFOD_PROGRESS=1 code does: print self-overwriting messages with > > \r rather than \n. That way many messages can come, but they don't > > overpower the screen. Really, the main reason I put in this > > progressfn into debuginfod-find was to help test that API within the > > testsuite. Maybe now, we don't need that option to do anything but > > set the env var, therby using the common code. > > It was indeed the specific testcase that made me keep the messages as > is. And it seems a good idea to have a code path that explicitly uses > the api calls instead of relying on the environment variable. Also I > found it a bit more difficult to combine the self-overwriting messages > with other verbose output. See my followup patch for producing verbose > output. I think the "per line" verbose/progress for debuginfod-find -v > works out well. Assuming I totally convinced you with the above speech I pushed this patch. On irc you said you also like the followup debuginfod_set_verbose_fd/DEBUGINFOD_VERBOSE patch, but I am waiting a bit longer with that one to see if there is any other feedback (also because that one exports a new interface). Cheers, Mark
[Bug libelf/26878] elflint reports error on SHT_X86_64_UNWIND .eh_frame section
https://sourceware.org/bugzilla/show_bug.cgi?id=26878 Mark Wielaard changed: What|Removed |Added Status|NEW |ASSIGNED CC||mark at klomp dot org --- Comment #1 from Mark Wielaard --- (In reply to Timm Bäder from comment #0) > Created attachment 12953 [details] > elfstrmerge.o compiled with clang > > gold and clang seem to emit .eh_frame sections of type SHT_X86_64_UNWIND. And we already handle gold, which (normally) outputs .eh_frame (and .eh_frame_hdr) without any relocations (because that is what a linker does, resolve the relocations :). So for non-ET_REL files we already seem to handle SHT_X86_64_UNWIND see: commit 22ec8efc1dd87cdc7892523457eb55990b967224 Author: Mark Wielaard Date: Sat Nov 10 23:33:03 2018 +0100 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. Signed-off-by: Mark Wielaard commit 4b0342b85b5b1a3d3636e06e3b5320954828dfb1 Author: Mark Wielaard Date: Tue Nov 6 12:01:25 2018 +0100 backends: Add x86_64 section_type_name for SHT_X86_64_UNWIND. Makes sure that eu-readelf and eu-elflint recognize and show the x86_64 specific section type correctly. Signed-off-by: Mark Wielaard Tested-by: Milian Wolff And I see that Navin just posted a fix for eblcheckreloctargettype: https://sourceware.org/pipermail/elfutils-devel/2020q4/003127.html -- You are receiving this mail because: You are on the CC list for the bug.
Re: Subject: [PATCH] Make elflint and libebl understand .rela.eh_frame like other section type
Hi Navin,
On Fri, 2020-11-13 at 20:17 +0530, Navin P via Elfutils-devel wrote:
> elflint doesn't recognize .rela.eh_frame like it does for other
> .rela sections.
Timm also noticed https://sourceware.org/bugzilla/show_bug.cgi?id=26878
I have an alternative patch that only recognizes SHT_X86_64_UNWIND for
x86_64, because it is an architecture specific section type.
Does the attached work for you?
Thanks,
Mark
From 00a25cf38d56bacae6b82c79cf226c22d12295a5 Mon Sep 17 00:00:00 2001
From: Mark Wielaard
Date: Tue, 17 Nov 2020 15:08:05 +0100
Subject: [PATCH] backends: Handle SHT_X86_64_UNWIND as valid relocation target
type.
The x86_64 abi defines a special section type for .eh_frame[_hdr],
SHT_X86_64_UNWIND, which is a valid relocation target type.
https://sourceware.org/bugzilla/show_bug.cgi?id=26878
Signed-off-by: Mark Wielaard
---
backends/ChangeLog | 5 +
backends/x86_64_init.c | 1 +
backends/x86_64_symbol.c | 8
3 files changed, 14 insertions(+)
diff --git a/backends/ChangeLog b/backends/ChangeLog
index 81d4127c..e88dedf9 100644
--- a/backends/ChangeLog
+++ b/backends/ChangeLog
@@ -1,3 +1,8 @@
+2020-11-17 Mark Wielard
+
+ * x86_64_symbol.c (x86_64_check_reloc_target_type): New function.
+ * x86_64_init.c (x86_64_init): Hook check_reloc_target_type.
+
2020-10-19 Mark Wielard
* Makefile.am (modules): Remove tilegx.
diff --git a/backends/x86_64_init.c b/backends/x86_64_init.c
index 8db9b643..be965fa6 100644
--- a/backends/x86_64_init.c
+++ b/backends/x86_64_init.c
@@ -63,6 +63,7 @@ x86_64_init (Elf *elf __attribute__ ((unused)),
eh->frame_nregs = 17;
HOOK (eh, set_initial_registers_tid);
HOOK (eh, unwind);
+ HOOK (eh, check_reloc_target_type);
return eh;
}
diff --git a/backends/x86_64_symbol.c b/backends/x86_64_symbol.c
index 98457bcb..d5f62e8f 100644
--- a/backends/x86_64_symbol.c
+++ b/backends/x86_64_symbol.c
@@ -71,3 +71,11 @@ x86_64_section_type_name (int type,
return NULL;
}
+
+/* The SHT_X86_64_UNWIND section type is a valid target for relocation. */
+bool
+x86_64_check_reloc_target_type (Ebl *ebl __attribute__ ((unused)),
+Elf64_Word sh_type)
+{
+ return sh_type == SHT_X86_64_UNWIND;
+}
--
2.18.4
Re: [PATCH] define SHT_LLVM_ADDRSIG section rather than error out
Hi Navin, On Fri, 2020-11-13 at 20:45 +0530, Navin P via Elfutils-devel wrote: > make elflint ignore it rather error as unsupported type. Other tools > like > readelf , objdump understand this section. Is there a specification of this section type? diff --git a/libelf/elf.h b/libelf/elf.h > index 6439c1a4..26420b45 100644 > --- a/libelf/elf.h > +++ b/libelf/elf.h > @@ -444,6 +444,7 @@ typedef struct > #define SHT_SYMTAB_SHNDX 18 /* Extended section indeces */ > #define SHT_NUM 19 /* Number of defined types. */ > #define SHT_LOOS 0x6000 /* Start OS-specific. */ > +#define SHT_LLVM_ADDRSIG 0x6FFF4C03/* llvm address sig */ > #define SHT_GNU_ATTRIBUTES 0x6ff5 /* Object attributes. */ > #define SHT_GNU_HASH 0x6ff6 /* GNU-style hash table. */ > #define SHT_GNU_LIBLIST 0x6ff7 /* Prelink library list */ elf.h comes from the glibc project. We should first try to upstream new constants there (glibc-al...@sourceware.org) > diff --git a/src/elflint.c b/src/elflint.c > index ef3e3732..62663800 100644 > --- a/src/elflint.c > +++ b/src/elflint.c > @@ -3905,6 +3905,7 @@ section [%2zu] '%s': size not multiple of entry > size\n"), > && shdr->sh_type != SHT_GNU_ATTRIBUTES > && shdr->sh_type != SHT_GNU_LIBLIST > && shdr->sh_type != SHT_CHECKSUM > + && shdr->sh_type != SHT_LLVM_ADDRSIG > && shdr->sh_type != SHT_GNU_verdef > && shdr->sh_type != SHT_GNU_verneed > && shdr->sh_type != SHT_GNU_versym Note that for various of these SHT_GNU extensions we actually do have some extra checks. Do we need to check anything for a section marked SHT_LLVM_ADDRSIG? Thanks, Mark
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/10/builds/587 Buildbot URL: https://builder.wildebeest.org/buildbot/ Worker for this Build: fedora-s390x Build Reason: Blamelist: Mark Wielaard BUILD FAILED: failed test (failure) Sincerely, -The Buildbot
Re: Buildbot failure in Wildebeest Builder on whole buildset
On Tue, 2020-11-17 at 15:09 +, 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/10/builds/587 > > Buildbot URL: https://builder.wildebeest.org/buildbot/ > > Worker for this Build: fedora-s390x > I couldn't replicate it and a rebuild is all green: https://builder.wildebeest.org/buildbot/#/builders/10/builds/588
Re: Subject: [PATCH] Make elflint and libebl understand .rela.eh_frame like other section type
with clang compiler build, before applying this patch 3 tests were failing and after applying the patch all tests pass. your patch is much better as it fixes the backend. On Tue, Nov 17, 2020 at 7:44 PM Mark Wielaard wrote: > > Hi Navin, > > > On Fri, 2020-11-13 at 20:17 +0530, Navin P via Elfutils-devel wrote: > > elflint doesn't recognize .rela.eh_frame like it does for other > > .rela sections. > > Timm also noticed https://sourceware.org/bugzilla/show_bug.cgi?id=26878 > > I have an alternative patch that only recognizes SHT_X86_64_UNWIND for > x86_64, because it is an architecture specific section type. > > Does the attached work for you? > > Thanks, > > Mark
Re: [PATCH] define SHT_LLVM_ADDRSIG section rather than error out
On Tue, Nov 17, 2020 at 7:49 PM Mark Wielaard wrote: > > Hi Navin, > > On Fri, 2020-11-13 at 20:45 +0530, Navin P via Elfutils-devel wrote: > > make elflint ignore it rather error as unsupported type. Other tools > > like > > readelf , objdump understand this section. > > Is there a specification of this section type? > > diff --git a/libelf/elf.h b/libelf/elf.h > > index 6439c1a4..26420b45 100644 > > --- a/libelf/elf.h > > +++ b/libelf/elf.h > > @@ -444,6 +444,7 @@ typedef struct > > #define SHT_SYMTAB_SHNDX 18 /* Extended section indeces */ > > #define SHT_NUM 19 /* Number of defined types. */ > > #define SHT_LOOS 0x6000 /* Start OS-specific. */ > > +#define SHT_LLVM_ADDRSIG 0x6FFF4C03/* llvm address sig */ > > #define SHT_GNU_ATTRIBUTES 0x6ff5 /* Object attributes. */ > > #define SHT_GNU_HASH 0x6ff6 /* GNU-style hash table. */ > > #define SHT_GNU_LIBLIST 0x6ff7 /* Prelink library list */ > > elf.h comes from the glibc project. > We should first try to upstream new constants there > (glibc-al...@sourceware.org) > > > diff --git a/src/elflint.c b/src/elflint.c > > index ef3e3732..62663800 100644 > > --- a/src/elflint.c > > +++ b/src/elflint.c > > @@ -3905,6 +3905,7 @@ section [%2zu] '%s': size not multiple of entry > > size\n"), > > && shdr->sh_type != SHT_GNU_ATTRIBUTES > > && shdr->sh_type != SHT_GNU_LIBLIST > > && shdr->sh_type != SHT_CHECKSUM > > + && shdr->sh_type != SHT_LLVM_ADDRSIG > > && shdr->sh_type != SHT_GNU_verdef > > && shdr->sh_type != SHT_GNU_verneed > > && shdr->sh_type != SHT_GNU_versym > > Note that for various of these SHT_GNU extensions we actually do have > some extra checks. Do we need to check anything for a section marked > SHT_LLVM_ADDRSIG? > We can do two things here a) Recognize the section exists but ignore its contents which is what i do. This needn't be the correct approach. You may need to check the contents to sht_llvm_addrsig but that is lot of work after the format has been frozen. https://www.mail-archive.com/netdev@vger.kernel.org/msg348254.html readelf output [22] .llvm_addrsig LOOS+0xfff4c03 ... b) If we don't want to recognize SHT_LLVM_ADDRSIG you can strip section from object file by objcopy -R .llvm_addrsig size.o conditionally based on clang compiler.
