I'm trying to debug why strip on mips isn't working properly.
What I see is that for the debug sections, sh_type is not set to
SHT_PROGBITS but to SHT_MIPS_DWARF.
The stripped file still ends up with the debug information it it,
and the file that is supposed to have the debug symbols in it
has it set to SHT_NOBITS, and is rather small.
I'm assuming this is because of the SHT_MIPS_DWARF. I'm not sure
how to find where it's going wrong.
This patch adds support for dwz multi debuginfo files to libdw.
Fedora is planning to use these in the next release:
The new DW_FORMs are proposed for DWARF5:
But are currently only a GNU extension written by the dwz tool:
libdw was already setup anticipating such a scheme, so adding support
wasn't so hard. Basically a Dwarf descriptor can now have an alternative
Dwarf descriptor that is consulted whenever one of the new DW_FROM_*alts
dwarf_begin_elf will find the right dwz alternative to use. But this is
currently tied somewhat to how fedora implemented this. There are also
two new functions dwarf_getalt () and dwarf_addalt () that can be used
to directly manipulate the alternative Dwarf descriptor. I anticipate
those will be used by some new libdwfl callbacks if we decide those are
necessary to support other ways to get/set alternative Dwarf
This is only lightly tested, but some quick stap queries on rawhide
packages that already had dwz files seemed to return the right results.
I did add some small test binary files and a readelf test to show the
results. I'll add some more tests once we decide whether this is the
proper way to support this.
Please take a look at the proposed implementation and let me know
whether it looks OK or some other approach might be better. I also
pushed this to the mjw/dwz branch.
the problem is reproduced when building elfutils with
-D_FORTIFY_SOURCE=2 and then:
# ./src/nm -f bsd ./src/nm
*** invalid %N$ use detected ***
The problem is in the following suite of format strings in nm.c:
[radix_hex] = "%8$s%2$0*1$" PRIx64 "%10$s %9$s%3$c%4$s %5$s",
[radix_decimal] = "%8$s%*" PRId64 "%10$s %9$s%3$c%4$s %5$s",
[radix_octal] = "%8$s%2$0*1$" PRIo64 "%10$s %9$s%3$c%4$s %5$s"
Note that 6$ and 7$ are missing, which is not allowed. With
_FORTIFY_SOURCE, glibc actually detects this condition and aborts.
printf is actually given all 10 arguments, and in another branch a
different set of formatting arguments are used, and those do contain 6$
and 7$. In the patch I reorder the arguments so that 6$ and 7$ become
9$ and 10$, and there are no gaps in any of the formatting strings.
I'm seeing a problem with all versions of elfutils from 0.152 up to
latest git head (a problem probably originating in 2007).
The symptoms are that using elf_cntl(..., ELF_C_READ, NULL) to pull a
whole ELF file into memory so you can close it causes assertion failures
inside elf64_getshdr() and gelf_getshdr():
scnwalk: elf32_getshdr.c:95: load_shdr_wrlock: Assertion `ehdr->e_ident != 1 || (! 1 && ((uintptr_t) file_shdr & (__alignof__ (Elf64_Shdr) - 1)) != 0)' failed.
These failures do not occur if you haven't used elf_cntl(), or if you
have used ELF_C_READ_MMAP rather than ELF_C_READ at elf_begin() time.
Testcase below. It looks to me like elf_begin.c:file_read_elf() is
concluding that the ELF file will require increased alignment to use (so
cannot be directly mapped), following which
elf32_getshdr.c:load_shdr_wrlock() concludes that it does *not* require
increased alignment, thus the assertion failure. These are perfectly
normal object files compiled on the same architecture, no byteswapping
needed and one would assume no alignment increase either: indeed you can
see this failure when you try to work over the very object files that
comprise the version of elfutils being tested.
I'll look into this further, but for now here's a testcase, which on
64-bit x86 fails for me with the assertion failure above when run with
e.g. elfutils/libelf/elf64_getshdr.o as a parameter (assuming you've
compiled elfutils so the object file is there, of course).
Removing the call to elf_cntl() (and the close(), obviously) fixes it,
as does changing ELF_C_READ to ELF_C_READ_MMAP.
int main (int argc, char *argv)
if (argc < 2)
fprintf (stderr, "syntax: scnwalk filename\n");
if (elf_version(EV_CURRENT) == EV_NONE)
fprintf (stderr, "elf_version failed: %s\n",
if ((fd = open (argv, O_RDONLY)) < 0)
fprintf (stderr, "Cannot open %s: %s\n",
argv, strerror (errno));
foo = elf_begin (fd, ELF_C_READ, NULL);
if (elf_cntl (foo, ELF_C_FDREAD) < 0)
fprintf (stderr, "Cannot elf_cntl(%p) for %s: %s\n", foo, argv,
for (sp = NULL; (sp = elf_nextscn (foo, sp)) != NULL;)
elf64_getshdr (sp); /* boom! */
This adds minimal low-level support for .debug_macro/DW_AT_GNU_macros as
proposed here http://www.dwarfstd.org/ShowIssue.php?issue=110722.1 and
implemented in gcc 4.7 (-g3). It is just enough to not barf on it when
we encounter the new attribute and to sanity check the attribute form
offsets. I added two small testfiles one using .debug_macinfo and one
using the new .debug_macros.
I haven't yet added the new DW_MACRO values to interpret the actual
contents. We might not even want/need to if gor higher-level support we
just reuse the DW_MACINFO values with the dwarf_getmacros (),
dwarf_macro_opcode (), dwarf_macro_param1 () and dwarf_macro_param2 ()
The new define/undef and start_file/end_file opcodes encode the same
information (and use the same values). There is no vendor_ext. There are
three new opcodes define_indirect, undef_indirect and
transparent_include. The first two are identical to define/undef, but
take their arguments differently. And transparent_include makes it
possible to reuse opcodes from somewhere else in the section. These
seems to be just the kind of thing that our interface wants to hide from
the user. So we would just return the original DW_MACINFO_define opcode
numbers and provide the param1/2 as we do now (just fetch them from
different places). Does that sound like a plan?
While writing another self test (on the mjw/dwarfstrings branch) I
noticed run-elflint-self.sh was running tests against the old location
of the ebl shared library backends (and silently succeeding because
the files weren't there). I pushed the attached patch to fix that.
The test still succeeds, but now tests a bit more.
this is to let everyone know that I pushed a fix that was proposed and
reviewed in the following bugzilla ticket (plus a change log and a
The substance is that in elfw2(LIBELFBITS, xlatetom), we shouldn't
require integer number of records when processing notes. Payload bytes
follow the header immediately, it's not an array of records as is the
The commit in question is bc0f7450. Hopefully I got the signed-off-by
The new .gdb_index version 7 encodes the kind of symbol.
I also made the printing of TUs slightly clearer by printing
the actual TU number and marking it with 'T' to distinquish
from the CU number. Small testcase added that shows the new format.