wiki
by Roland McGrath
I wrote a couple more new wiki pages, and put pointers to all the new ones
near the end of the RoadMap page. These don't have as much detail, wisdom,
or coherence as we might have hoped. But I think they include at least a
mention of everything that I can still find in the corners of my cobwebbed
mind that I always hoped we would work on one day. As always, edit as you
see fit and ask on this list for any clarifications or more detail you
would like.
They tell me that my access to this email address will be turned off in a
couple of hours now. I am already on this mailing list at my new address
so you can just post here to ask me anything more.
Thanks,
Roland
13 years, 1 month
run-elflint-self.sh fails on alpha
by Ryan Hill
With most 0.14x versions, last confirmed with 0.151, run-elflint-self.sh
fails with many messages such as:
section [ 5] '.dynsym': symbol 61: unknown bit set in st_other
section [ 5] '.dynsym': symbol 64: unknown bit set in st_other
section [28] '.symtab': symbol 27: unknown bit set in st_other
section [28] '.symtab': symbol 34: unknown bit set in st_other
section [28] '.symtab': symbol 35: unknown bit set in st_other
section [28] '.symtab': symbol 36: unknown bit set in st_other
section [28] '.symtab': symbol 37: unknown bit set in st_other
section [28] '.symtab': symbol 38: unknown bit set in st_other
section [28] '.symtab': _GLOBAL_OFFSET_TABLE_ symbol value 0x120014010 does not match .got section address 0x120014000
Full build logs are available at https://bugs.gentoo.org/329875
--
fonts, gcc-porting, it makes no sense how it makes no sense
toolchain, wxwidgets but i'll take it free anytime
@ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
13 years, 1 month
https://fedorahosted.org/elfutils/wiki/DwarfArchive
by Roland McGrath
I've just added this wiki page with my thoughts off the cuff about the
"consolidated debug archive" idea I've had for a long time. Edit it
as you see fit and ask here for any things you want clarified. I'm
pretty sure I had some more specific thoughts about the format and
about implementation issues related to reading or writing it, but they
are not reading coming to mind right now.
I discussed this (without notes) with the Red Hat GDB team in Toronto
last October. But neither Mark nor Petr was at that meeting as I
recall. It's possible someone there took notes about what I said and
that there was something I described there that I've overlooked in
this write-up.
Thanks,
Roland
13 years, 1 month
https://fedorahosted.org/elfutils/wiki/DwarfReaderSharing
by Roland McGrath
I've just added this wiki page with my thoughts off the cuff
about libdw changes we will want to reduce memory usage and
redundant computation/caching when we have some more sharing
happening in the file encodings. Edit it as you see fit and
ask here for any things you want clarified.
Thanks,
Roland
13 years, 1 month
https://fedorahosted.org/elfutils/wiki/DwarfRelocatable
by Roland McGrath
I've just added this wiki page with my thoughts off the cuff
about the roland/relocate branch and issues for the future of
ET_REL handling. Edit it as you see fit and ask here for any
things you want clarified.
Thanks,
Roland
13 years, 1 month
denser dwarf macro information
by Mark Wielaard
This is just for the archives. I was looking at some other dwarf
information that could be compressed. There was a proposal from Jim
Blandy a long time ago on denser dwarf macro information
(the .debug_macinfo sections).
http://gcc.gnu.org/ml/gcc/2002-04/msg00366.html
As far as I can see this idea was never implemented. I don't know why
though. Maybe a simpler approach that just gets the strings shared is
more effective? Same seems to be true for .debug_line, which also
doesn't reference strings through .debug_str. Is that a good or bad
idea?
13 years, 1 month
Some dwarf "nitpicks"
by Mark Wielaard
Hi,
While hunting down some issues I had with dwarf_output on the examples
in the gdb testsuite I came across some "that doesn't look like valid
dwarf" things. Most of these were already discussed off list with Petr
to make sure dwarflint knows about them. But it seems better to have a
public archive of these issues, so others can help us interpret whether
or not they are really "invalid dwarf", just confusing, or something
else.
Silly usage note. If you are seeing lots of:
error: .rela.debug_info: offset 0x6: invalid relocation 10 (<INVALID
RELOC>).
you are probably running dwarflint against old elfutils libraries. Make
sure LD_LIBRARY_PATH is explicitly set to the freshly build libraries.
dwarflint would sometimes detect some low-level dwarf datastructure
corruption but then would run some of the high-level tests anyway. That
didn't end well, because dwarflint would crash on the bad data. Petr
already fixed this on the dwarf branch.
The gdb testsuite contains a lot of "minimal dwarf" examples (mostly
written by hand. There are some assumptions that might or might not be
valid. You can get some of these also with some minimal C "program".
$ echo > empty.c
$ gcc -g -c empty.c
$ dwarflint empty.o
error: .debug_abbrev: couldn't load CU headers; assuming CUs are of
latest DWARF flavor.
error: .debug_abbrev: no abbreviations.
error: .debug_info: data not found.
$ echo "static int empty;" > empty.c
$ gcc -g -c empty.c
$ eu-dwarflint empty.o
error: .debug_line: table 0: sequence of opcodes not terminated with
DW_LNE_end_sequence.
These examples really don't have any .debug_line info, just an
short debug_line section header. Maybe gcc shouldn't output any header
at all, or maybe it should make the empty table by having only the
DW_LNE_end_sequence in it instead? Or should dwarflint ignore the table
if the header says the table is empty?
Attached are also some examples that show "bad child" marking in a dwarf
file. These can happen easily when you are writing dwarf examples by
hand (as is done in the gdb testsuite a lot). The diff of the .s files
will show that "accidentally" some DIEs were marked as not having
children but the "end of child list" markers are still there (it also
tweaks the siblings to be some other reference type, because dwarflint
does see the discrepancy in that case - go dwarflint! - except my
original didn't have sibling markers of course...).
The result is that something that relies on dwarf_siblingof will just
not see the last few DIEs. Since we are under the impression the CU is
done. This caused havoc for dwarf_output which was suddenly missing some
referenced DIEs. But you can also see that eu-readelf will just stop
early (interestingly binutils readelf will show them (but with an
indentation of zero, which is rather odd for non-CU dies).
I am hoping that since unit headers have a length and the "top-level" CU
die needs to have children that cover the whole unit dwarflint somehow
can detect that there is something odd going on with the children
relationship even if there are no sibling_AT markers. A zero or negative
"indentation level" for a DIE that isn't the top-level CU DIE should
probably cause at least a warning.
Cheers,
Mark
13 years, 1 month
dwarf4 Separate Type Unit Entries
by Mark Wielaard
Hi,
I was talking to Tom Tromey about the general idea of dwarf compression
through identification of similar DIE trees and replacing them with a
single instance and then referencing those similar trees in the main
tree through the use of DW_TAG_imported_unit DIEs that have a
DW_AT_import attribute pointing to the DW_TAG_partial_unit DIE tree that
we separated out.
Now dwarf4 adds another unit variant, the DW_TAG_type_unit (section
3.1.3) which is like a partial unit, but only for types. They cannot be
imported normally, but only through a DW_AT_signature attribute that
references the DW_TAG_type_unit through a 64bit signature/hash instead
of a normal reference, instead of the DIE having an DW_AT_declaration.
This seems a special case variant of the way we do dwarf compression.
But it may be indicative of the gains we might be seeing. Tom said that
for a gdb build on F14 -g -O2 -vs- -gdwarf-4 -O2, gives a size reduction
from 16M to 11M. The .debug_info went from 70ffa6 -> 17a63c, the abbrev
shrunk and the .debug_types section (where the type units are stored) is
smaller than the difference in debug_info.
One advantage of the type unit compression is that gdb already has some
support for it, while the support for imported partial units is still on
some branch.
So now we probably should figure out how to cash in on this alternative
compression variant. Does it make sense to create a dwarf writer that
outputs DW_TAG_type_units instead of DW_TAG_partial_units if they only
contain type information DIEs (I am not completely clear on what DIEs
are and which are not allowed to be included in the type units). But the
references seem somewhat bloated (don't know if that really adds up). Or
does it make more sense to transform the type units into partial units
when we read them in? But what would be needed to get the libdw/C++
dwarf branch to properly parse type units?
Cheers,
Mark
13 years, 1 month
bswap_32() macro with postincrement
by Kurt Roeckx
Hi,
It seems that the bswap_32() is causing this error on m68k:
gnuhash_xlate.h: In function `elf_cvt_gnuhash':
gnuhash_xlate.h:92: error: operation on `src32' may be undefined
The problem is that bswap_32() is a macro, and so the
postincrement could be executed multiple time. But
I assume that a macro like that is supposed to protect
the caller from causing that problem, but I'm not really
sure.
Anyway, this patch will fix the issue on m68k:
diff --git a/libelf/gnuhash_xlate.h b/libelf/gnuhash_xlate.h
index d79764d..4783d6b 100644
--- a/libelf/gnuhash_xlate.h
+++ b/libelf/gnuhash_xlate.h
@@ -89,7 +89,8 @@ elf_cvt_gnuhash (void *dest, const void *src, size_t len, int encode)
dest32 = (Elf32_Word *) &dest64[bitmask_words];
while (len >= 4)
{
- *dest32++ = bswap_32 (*src32++);
+ *dest32++ = bswap_32 (*src32);
+ ++src32;
len -= 4;
}
}
Bug report and patch provided by Thorsten Glaser <tg(a)mirbsd.de>,
more information is at http://bugs.debian.org/595496
Kurt
13 years, 1 month
DIE chains not ending with null entry
by Petr Machata
Hi,
over the last couple of days I've been experimenting with garbage DWARF
files (essentially I take a working DWARF file, flip a random bit, and
see if dwarflint fails). In one of such garbage files, a DIE chain ends
like this:
[ 98] pointer_type
byte_size (data1) 8
type (ref4) [ 9e]
[ 9e] pointer_type
byte_size (data1) 8
type (ref4) [ a4]
[ a4] base_type
byte_size (data1) 1
encoding (data1) signed_char (6)
name (strp) "char"
[ ab] pointer_type
byte_size (data1) 8
type (ref4) [ 6c]
At this point the section suddenly ends. The pointer_type entries all
use one abbreviation, the has_children flag of which has been flipped to
DW_CHILDREN_yes. The nesting that you see has not been there before.
Dwarflint sort of diagnoses this, giving a cascade of messages:
warning: .debug_info: DIE 0xab (abbreviation 113): abbrev has_children, but the chain was empty.
warning: .debug_info: DIE 0xab (abbreviation 113): DIE chain not terminated with null entry.
warning: .debug_info: DIE 0x9e (abbreviation 113): DIE chain not terminated with null entry.
warning: .debug_info: DIE 0x98 (abbreviation 113): DIE chain not terminated with null entry.
warning: .debug_info: DIE 0xb (abbreviation 0): DIE chain not terminated with null entry.
The thing is, many real-world DWARF files have this problem, so the
message is now only a warning in --strict mode, and such files have
always been deemed safe for consumption by <dwarf>. Alas, the case that
we see here is special:
Dwarf_Die die_mem, *die = dwarf_offdie (dw, 0xab, &die_mem);
Dwarf_Die child;
dwarf_child (die, &child); // this actually passes
So libdw happily gives us a DIE that supposedly lies at 0xb1,
interpreting the first bytes of .debug_abbrev as DIE.
I might turn that combination (empty chain + no null entry) into a hard
error in dwarflint, but that seems rather convoluted. I think this is
something that should be fixed in libdw. I've done that, the result is
on the branch pmachata/dwarf_child_overrun.
Thanks,
PM
13 years, 1 month