Jan> Not yet in GDB upstream, Tom Tromey AFAIK plans to upstream it.
Thanks for the reminder. I sent it today.
Tom
___
elfutils-devel mailing list
elfutils-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/elfutils-devel
> "Mark" == Mark Wielaard writes:
Mark> Only completely unknowns are DW_OP_GNU_uninit
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00068.html
IIRC this one is badly specified, and you need a special gcc option to
ever get it. AFAIK nobody uses it.
Mark> and DW_OP_GNU_encoded_addr.
http:/
55 tests/testfile59.bz2
create mode 100644 tests/typeiter.c
diff --git a/libdw/ChangeLog b/libdw/ChangeLog
index 98b67f4..f96c0d1 100644
--- a/libdw/ChangeLog
+++ b/libdw/ChangeLog
@@ -1,3 +1,9 @@
+2012-03-19 Tom Tromey
+
+ * libdw_findcu.c (findcu_cb): Move
> "Roland" == Roland McGrath writes:
Roland> Either we should handle the full generality of ET_REL files
Roland> thoroughly--a lot of work that I'm quite doubtful is
Roland> worthwhile--or we should stick to the existing decision that we
Roland> handle ET_REL files only for the very special c
> "Roland" == Roland McGrath writes:
Tom> There may not be a link time -- you can "pahole something.o". If the .o
Tom> was made with -fdebug-types-section, then it may have multiple such
Tom> sections. This is just a consequence of the use of different comdat
Tom> sections for each type uni
> "Roland" == Roland McGrath writes:
Roland> Can you start with some background on why the sections aren't
Roland> joined at link time?
Sure, sorry.
There may not be a link time -- you can "pahole something.o". If the .o
was made with -fdebug-types-section, then it may have multiple such
s
644
--- a/libdw/ChangeLog
+++ b/libdw/ChangeLog
@@ -1,5 +1,34 @@
2012-03-20 Tom Tromey
+ * libdw_findcu.c (__libdw_intern_next_unit): Use
+ dwarf_next_unit_or_section. Initialize CU's section index.
+ (findcu_cb): Compare section indices.
+ (__libdw_findcu)
Tromey
+ * dwarf_begin_elf.c (check_section): Remove 'inscngrp' argument.
+ (global_read, scngrp_read): Update.
+
+2012-03-20 Tom Tromey
+
* libdwP.h (struct Dwarf) [n_sections]: New field.
[sectiondata]: Change type.
* dwarf_end.c (__libdw_free_z
/libdw/ChangeLog
+++ b/libdw/ChangeLog
@@ -1,5 +1,15 @@
2012-03-20 Tom Tromey
+ * libdwP.h (struct Dwarf) [n_sections]: New field.
+ [sectiondata]: Change type.
+ * dwarf_end.c (__libdw_free_zdata): Use n_sections.
+ (dwarf_end): Free the section data
+1,11 @@
2012-03-20 Tom Tromey
+ * libdwP.h (IDX_debug_types): Move just before IDX_last.
+ * dwarf_begin_elf.c (dwarf_scnnames): Move .debug_types to the
+ end.
+
+2012-03-20 Tom Tromey
+
* libdwP.h (struct Dwarf_Section): New.
(Dwarf_Section): New typedef
|6 ++
src/readelf.c |4 ++--
22 files changed, 114 insertions(+), 67 deletions(-)
diff --git a/libdw/ChangeLog b/libdw/ChangeLog
index 98b67f4..8a556ec 100644
--- a/libdw/ChangeLog
+++ b/libdw/ChangeLog
@@ -1,3 +1,27 @@
+2012-03-20 Tom Tromey
+
+ * libdwP.h (struct
I added support for multiple .debug_types sections to libdw.
I consider this a WIP patch. There is one definitely bad patch (#4) and
of course the usual stylistic things; in particular the new CU-iterating
function (in patch #5) is pretty ugly.
I'd appreciate feedback on this.
Tom
_
> "Mark" == Mark Wielaard writes:
Mark> This looks correct to me. And I saw your systemtap patch that adds a
Mark> testcase for it. But I would like Roland to take a look too, because
Mark> he wrote the original dwarf_next_unit () support.
Ok.
I can write an elfutils test as well if you wan
Tom
From 1b85426f7a1fa39cfb9ff83b864e825072115847 Mon Sep 17 00:00:00 2001
From: Tom Tromey
Date: Mon, 19 Mar 2012 11:46:45 -0600
Subject: [PATCH] Fix bug using dwarf_next_unit to iterate over .debug_types
* libdw_findcu.c (findcu_cb): Move earlier.
(__libdw_intern_next_unit
Mark> Here is a patch from Jakub (with some small tweaks to the output
Mark> from me). It adds typed DWARF stack support (which is now in gcc trunk)
Mark> where DW_OP_GNU_entry_value is supported. readelf -w works. For more
Mark> background on the new ops see http://www.dwarfstd.org/doc/040408.1.ht
> "Mark" == Mark Wielaard writes:
Mark> To be honest I would like gdb to drop this section. It eats up valuable
Mark> space that I think we could use better and/or in other ways that make it
Mark> easier to add other consumers for it. But only by actually supporting it
Mark> now and working t
> "Ulrich" == Ulrich Drepper writes:
Ulrich> Why would you assume this is even possible. The format is exclusively
Ulrich> used by gdb. The gdb people unilaterally make changes. If gdb cannot
Ulrich> read the info in a file it'll ignore it. Versioning all the changes
Ulrich> etc is likely
Mark> IMHO the current documentation is fine, it should just be moved
Mark> to a more easily discoverable location.
Tom> Ok. I will give it a shot.
It is in gdb.texinfo now.
Tom
___
elfutils-devel mailing list
elfutils-devel@lists.fedorahosted.org
htt
> "Mark" == Mark Wielaard writes:
Mark> Note that libdw relies on .debug_aranges. For example dwarf_addrdie (),
Mark> which returns the CU DIE containing a given address, just returns NULL
Mark> if the aranges section isn't there.
Yeah. What makes this bug theoretical is that, AFAIK, nobody
> "Mark" == Mark Wielaard writes:
Tom> There is no way to distinguish between a CU that does not have a
Tom> corresponding .debug_aranges entry, and a CU that simply has no
Tom> addresses to represent. This is ambiguous because .debug_aranges is an
Tom> optional section.
Tom> This is semi-p
Mark> IMHO the current documentation is fine, it should just be moved
Mark> to a more easily discoverable location.
Ok. I will give it a shot.
Tom> There are 3 indices in DWARF. AFAIK .debug_aranges doesn't really have
Tom> problems, except one theoretical one that everybody has agreed to
Tom> i
> "Mark" == Mark Wielaard writes:
Mark> Do you think it makes sense to support printing this format, or will you
Mark> be arbitrarily changing it from time to time? Having it more prominently
Mark> documented would be nice.
We do change it from time to time.
We could document it elsewhere.
Ulrich> The best solution in that case is to have gdb provide
Ulrich> the decoder.
It does, in the form of binutils readelf --debug-dump=gdb_index.
Tom
___
elfutils-devel mailing list
elfutils-devel@lists.fedorahosted.org
https://fedorahosted.org/mailma
Tom> When constructing the anonymous type, gdb uses the linkage name to give
Tom> the type the name `t'. What is specifically useful to gdb about this
Tom> approach is that it can be decided locally whether this is necessary.
Tom> Previous iterations required a lot of complicated code to defer giv
Mark> MIPS_linkage_name(string) "1t"
Mark> So the first question is, how do I demangle this "1t"?
demangled = cplus_demangle (part_die->linkage_name, DMGL_TYPES);
Mark> Is that just a temporary name given to the anonymous struct?
Sort of. In C++ this construct gives a na
> "Roland" == Roland McGrath writes:
>> See GCC PR 47510.
>>
>> Basically, this is a GCC extension. Partly it is there to make the
>> implementation in GDB simpler, but it is also a DWARF reflection of a
>> C++ feature that otherwise has no natural existing representation (at
>> least IMO).
> "Mark" == Mark Wielaard writes:
Mark> - DW_TAG_union_type and DW_TAG_structure_type with DW_AT_linkage_name
Mark> set (but not DW_AT_external, which on itself makes sense). These are
Mark> unexpected because the dwarf spec doesn't explain why or how these would
Mark> be necessary.
See GCC
> "Mark" == Mark Wielaard writes:
Mark> Tom said that for a gdb build on F14 -g -O2 -vs- -gdwarf-4 -O2,
Mark> gives a size reduction from 16M to 11M.
Yeah; I was pretty surprised to see such a big difference in a plain C
program.
Mark> One advantage of the type unit compression is that gdb
> "Mark" == Mark Wielaard writes:
Mark> specification=[0x28889b]
Mark> byte_size=0x8
Mark> decl_file="...libdw/c++/dwarf_data" decl_line=761
Mark> containing_type=[0x2898c8]>
Mark> Is this valid dwarf? Can a structu
> "Roland" == Roland McGrath writes:
Roland> The only rationale I've heard for empty ranges is Tom's idea
Roland> that every CU should be the rhs of some .debug_aranges entry
Roland> just so you can be sure that .debug_aranges is really complete
Roland> (vs. a buggy old GCC, or some different
Tom>Consider checking that every CU has an arange entry.
Tom>This is not strictly required, but it is nicer for consumers.
Tom>ISTR filing a bug about this in GCC bugzilla.
[...]
Roland> Every CU that has any PCs (i.e. compile_unit has low_pc,
Roland> high_pc, or ranges attributes at
Roland> https://fedorahosted.org/elfutils/wiki/DwarfLint
Roland> Please follow up on elfutils-devel@lists.fedorahosted.org about
Roland> details.
Roland> If you have any more suggestions for checks, please post them to
Roland> elfutils-devel and we'll get them onto the TODO list.
Roland>
> "Roland" == Roland McGrath writes:
Roland> What sources are you working with? .debug_types and
Roland> .debug_pubtypes were added to that list before version 0.144
Roland> (commit a14b4eb on 2009/10/5).
I was on a branch other than master, and forgot to look first. Sorry
about that.
Tom
nderstanding is that
.debug_types is not handled by elfutils in general yet.
Tom
diff --git a/libebl/ChangeLog b/libebl/ChangeLog
index ba3dc7d..cdcc3a0 100644
--- a/libebl/ChangeLog
+++ b/libebl/ChangeLog
@@ -1,3 +1,8 @@
+2010-07-07 Tom Tromey
+
+ * eblopenbackend.c (default_debugscn_p):
> "Roland" == Roland McGrath writes:
Mark> I couldn't find a definition for DW_OP_GNU_uninit. What does it
Mark> express?
Roland> Yeah, good question. It's no my list to take it up on archer
Roland> and/or gcc lists to get a good specification for it. It seems
Roland> to be a not-really-us
> "Mark" == Mark Wielaard writes:
Mark> For completeness, should it also include DW_OP_form_tls_address
Mark> (although gcc seems to emit DW_OP_GNU_push_tls_address) and
Mark> DW_OP_bit_piece (which gcc doesn't seem to emit)?
GCC doesn't emit it now, but maybe only because GDB doesn't suppor
36 matches
Mail list logo
