I've added some read-side C++ support for rangelistptr attr values and for
aranges. The dwarf::range_list class is really just for the DW_AT_ranges
attr comparisons. debug_info_entry.ranges () is what things will use for
semantics (it uses dwarf_ranges, i.e. combining either ranges or lo/hi pc).
dwarf.aranges () is a slow, copying presentation of the aranges suitable
for comparing elements to a compile_unit.ranges (). I didn't make it a
thin reader because we won't really use this outside of dwarflint.
(The unit_by_addr, whenever I get to it, will be a thin layer on
dwarf.aranges () yields a map of compile_unit to arange_list.
arange_list and the other flavors from die.ranges () or attr_value.ranges ()
all act like set<pair<Dwarf_Addr, Dwarf_Addr>> (or unordered_set) for
templatey purposes. You can compare them to each other, and all have
a .to_string () for pretty-printing.
The comparisons canonicalize by coalescing contiguous adjacent ranges.
That is true for "semantically equal", and also notes for later what we can
do as an optimization in generating ranges and aranges for output. But
possibly one might want not to coalesce for dwarflint comparison, since
ranges/aranges not matching exactly from the generator seems suspicious.
Lots of tiny ranges that are actually adjacent and contiguous but generated
as many entries can be normal. It's especially common for C++ where
everything is in a zillion tiny little .gnu.linkonce sections. When the
program is finally linked, it all winds up in .text and packed in, so the
many entries have adjacent addresses and look superfluous. In fact they
are superfluous and we can coalesce them away for smaller .debug_aranges
sections. But they're not suspicious, since they made perfect sense as
emitted before the final link.
Another thing to note for output-side optimization is that it's common to
have many entries that are adjacent except for a gap of a few bytes. This
too is normal and correct as generated. The gaps are alignment bits in
.text between multiple entry points in a CU. It's correct precision to
leave the gaps there in DIE range lists. But .debug_aranges exists purely
for quick lookup of the containing CU. So when a gap that's not part of
any CU is small (i.e. less than sh_addralign of the section containing both
addresses), we can just coalesce across it so the addresses in the gap map
to the CU it's in the middle of. If someone is actually searching for the
gap addresses, they will just descend the CU and not find it, which is
fine. More commonly, we'll reduce the entries to just a few for each CU
and keep the table small so searches are fast.
The following is what I used to test this. But it really belongs in a
dwarflint high-level check, not in dwarfcmp. This code already showed some
interesting anomalies. dwarflint should eventually show the differences in
some way that's especially helpful for debugging the generators. That will
be handy in diagnosing and reporting the details of what GCC does wrong.
Someone should investigate these anomalies, but for now it will have to
take a back seat to our critical path on DWARF writing/transformation work.
diff --git a/src/dwarfcmp.cc b/src/dwarfcmp.cc
index 522b719..0000000 100644
@@ -304,6 +304,20 @@ main (int argc, char *argv)
dwarf file1 (dw1);
dwarf file2 (dw2);
+ const dwarf::aranges_map aranges = file1.aranges ();
+ for (dwarf::aranges_map::const_iterator i = aranges.begin ();
+ i != aranges.end ();
+ const dwarf::compile_unit &cu = (*i).first;
+ const dwarf::arange_list &ranges = (*i).second;
+ cout << (cu.ranges () == ranges ? "match" : "mismatch")
+ << " aranges " << ranges.to_string () << " vs CU-ranges "
+ << cu.ranges ().to_string () << endl;
result = !(file1 == file2);
= Work done last week:
* Time spent on elfutils: ~50%
* This was a bad week. The little time I spent on elfutils was
actually several false starts and code thrown away eventually. Later in
the week my RHEL responsibilities have kicked in and I spent the
remainder of the week on that. So at least I've updated the dwarflint
= Work scheduled for this week:
* Expected time spent on elfutils: 50-80%.
* Fix 10-byte LEB128 that Roland posted about. (This should
actually be already in.)
* Write .debug_ranges validation.
(Actually it's 2009-1-27 here now.)
Actual time on elfutils: 80%
* posted to dwarf-discuss list wrt imported_unit and reference identity
-> upshot: don't use imported_unit non-toplevel context unless not ref'd
-> might limit redundancy elimination in e.g. template instantiations
* 0.139 release
-> made fedorahosted release
-> 0.139-1 in rawhide, F-9/F-10 updates-testing
-> compatibility nit hacking
* attr value interfaces
** read-only side somewhat there
** still missing: refs, lines, macinfo, known enums, loclist, reloc
Expected time on elfutils: 80%
* post to dwarf-discuss wrt more imported_unit questions
*** vs CU-context attrs (stmt_list, macro_info): imported or importer?
*** vs .debug_macinfo
* attr value interfaces
** dwarf_edit counterpart
** contemplate references
* post or wikiize wrt dwarf_output class design
Two things occur to me wrt .debug_aranges validation:
It's not an automatic error if there is no .debug_aranges section (or a
completely empty one). It's a high-level check that the aranges match the
CUs--but you can legitimately have just CUs that don't have any addresses.
You do a connectivity check for the CU pointers. It would also be useful
to do a "suspicious" check that there aren't multiple separate sets
pointing to the same CU. It is not clearly invalid per se to have
multiples, but it is clearly weird. Our high-level checks probably won't
try to account for multiple sets for a CU being correct.
Also, now that I look at your aranges code, I assume you either haven't
tested it yet or haven't pushed the current code. The "Covered length"
parsing is totally bogus. What follows the CU offset are two single bytes
(address_size, segment_size), not another offset-size value that's a
length. What you should check there is that the address_size matches the
address_size in the CU header, and that the segment_size is 0.
Who do I complain at about the 'transif' user committing crap to my repo?
Whether done by robot or human, someone has to be responsible, and
responsive to project administrators. The L10N/FAQ page is real short on
prominent answers to obvious questions for project admins like this one.
As requested, I enabled transif to commit to the elfutils repo on
git.fedorahosted.org. Then we got the following commit.
I understand doing a dummy commit to test the access.
I don't understand doing one and then not reverting it.
I don't understand committing bogus mis-formatting to my po/ChangeLog.
If you can't even do a dummy commit so that it's harmless to the project,
why should I trust you and your robot to be allowed to commit to our repo?
We will very much appreciate the contributions of translators, and we
recognize the great contribution of automating and streamlining the process
for translators and project maintainers. But lack of streamlined
automation is better than robots (or human contributors, however
well-meaning) we can't trust to touch our project's files.
Author: Dimitris Glezos <dimitris(a)glezos.com>
Date: Wed Jan 21 01:04:45 2009 +0000
Dummy commit, testing Transifex at
Transmitted-via: Transifex (translate.fedoraproject.org)
diff --git a/po/ChangeLog b/po/ChangeLog
index bbb72fa..95a51f3 100644
@@ -1,4 +1,7 @@
-2007-06-05 Ulrich Drepper <drepper(a)redhat.com>
+Dummy commit, testing Transifex at
+Transmitted-via: Transifex (translate.fedoraproject.org)2007-06-05 Ulrich Drepper <drepper(a)redhat.com>
* Makefile.in.in: Update from gettext 0.16.1.
* Rules-quot: Likewise.
diff --git a/po/Makefile.in.in b/po/Makefile.in.in
index 5022b8b..7cdfad7 100644
@@ -9,6 +9,7 @@
# General Public License and is *not* in the public domain.
# Origin: gettext-0.16
PACKAGE = @PACKAGE@
VERSION = @VERSION@
When systemtap is bundled with elfutils (configure --with-elfutils) we
compile with -fPIE. This doesn't work with current trunk elfutils git on
i386 anymore because of the TEXTREL check in libdw/Mafefile.am:108
if readelf -d libelf.so | fgrep -q TEXTREL; then exit 1; fi
Would it be possible to make this work again?