On Wed, 2011-04-27 at 22:23 +0200, Jan Kratochvil wrote:
> Please support version 4 and 5 now when it gets checked in.
> http://sourceware.org/ml/gdb-cvs/2011-04/msg00179.html
Thanks, done.
Mark
___
elfutils-devel mailing list
elfutils-devel@list
On Fri, 15 Apr 2011 00:35:44 +0200, Mark Wielaard wrote:
> + if (vers != 4)
> +{
> + printf (gettext (" unknown version, cannot parse section\n"));
> + return;
> +}
Please support version 4 and 5 now when it gets checked in.
http://sourceware.org/ml/gdb-cvs/2011-04/msg0
On Thu, 2011-04-21 at 14:28 -0600, Tom Tromey wrote:
> But... first, we try not to change it, because changes are disruptive.
> Second, a change requires a version bump and an update to the
> documentation (in the past this was just a comment, but in the future it
> will require a change to gdb.tex
> "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
On Thu, Apr 21, 2011 at 14:15, Frank Ch. Eigler wrote:
> OK, let's say arguendo .gdb_index undergoes a few versions over the
> course of a year. (One may assume that it's self-identifying.)
> Why not pretty-print them all?
Why would you assume this is even possible. The format is exclusively
us
On Thu, 2011-04-21 at 11:12 -0700, Roland McGrath wrote:
> Obviously it's not a catastrophic issue.
Yeah :) Sorry this is taking so much electrons. Clearly the time to
write these emails has taken more energy than writing the actual code.
But better to talk it out than to just let it stand there w
Obviously it's not a catastrophic issue. But these are tools for ELF and
DWARF, not for one-off formats produced and used only by a single tool.
Even sdt has two whole disjoint consumers.
___
elfutils-devel mailing list
elfutils-devel@lists.fedorahosted.
Hi, Roland -
roland wrote:
> > I'm curious why you think that is a showstopper distinction. What
> > harm would come from teaching eu-readelf how to pretty-print some
> > "non-interchange" formats, if they are reasonably stable, don't
> > require much eu-readelf uglification?
>
> There is no re
> I'm curious why you think that is a showstopper distinction. What
> harm would come from teaching eu-readelf how to pretty-print some
> "non-interchange" formats, if they are reasonably stable, don't
> require much eu-readelf uglification?
There is no reason to think that .gdb_index format is r
Hi, Roland -
> > I thought the objection was that it wasn't properly
> > specified/standardized yet. Which it now is IMHO.
>
> It's not an interchange format, it's a gdb format.
I'm curious why you think that is a showstopper distinction. What
harm would come from teaching eu-readelf how to pre
On Thu, 2011-04-21 at 10:17 -0700, Roland McGrath wrote:
> > I guess I could just use binutils readelf then. Pity, since I like the
> > eu-readelf output better to be honest.
>
> You can just write your tool using libelf and with the output format you
> like. It's just not part of eu-readelf.
It
> I thought the objection was that it wasn't properly
> specified/standardized yet. Which it now is IMHO.
It's not an interchange format, it's a gdb format.
> I guess I could just use binutils readelf then. Pity, since I like the
> eu-readelf output better to be honest.
You can just write your t
On Thu, 2011-04-21 at 09:16 -0700, Roland McGrath wrote:
> > http://sourceware.org/gdb/current/onlinedocs/gdb/Index-Section-Format.html
> > I hope that resolves Roland's doubts about the usefulness of
> > parsing/outputting this section with eu-readelf.
>
> It really doesn't have anything to do wi
> http://sourceware.org/gdb/current/onlinedocs/gdb/Index-Section-Format.html
> I hope that resolves Roland's doubts about the usefulness of
> parsing/outputting this section with eu-readelf.
It really doesn't have anything to do with the objection at all.
> It was already useful BTW. We found out
On Mon, 2011-04-18 at 11:44 -0600, Tom Tromey wrote:
> > "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.
On Wed, 2011-04-20 at 12:01 -0600, Tom Tromey wrote:
> 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.
Thanks.
http://sourceware.org/gdb/current/onlinedocs/gdb
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
On Mon, 2011-04-18 at 09:43 -0600, Tom Tromey wrote:
> It might mean that this CU covers no addresses -- and this would be very
> convenient, since it would mean that .debug_aranges is a reliable index
> in the sense of being both complete and correct.
>
> But, because .debug_aranges is optional i
> "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
On Mon, 2011-04-18 at 08:50 -0600, Tom Tromey wrote:
> 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> ignore. I'm not sure why I didn't just use this instead of putting the
> Tom> ranges int
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
Hi Tom,
> We could document it elsewhere. Where would you suggest?
I looked or it in the manual (either user or internal):
http://sourceware.org/gdb/documentation/
Since the save gdb-index command is described in:
http://sourceware.org/gdb/current/onlinedocs/gdb/Index-Files.html
IMHO the curren
> What about a compromise? We don't print is by default
> with -w/--dump-debug, but only when explicitly requested?
Now that I know binutils readelf also support
--debug-dump=.gdb_index I played a bit with it to check the
output agrees. It does include the section in case of using
-w, so we should
On Fri, Apr 15, 2011 at 12:18, Tom Tromey wrote:
> A more "end-to-end" solution would be nice. What I mean by this is that
> right now the index generation is a separate step, and it involves
> running GDB, so for daily development it is basically not worth doing.
> It is only worthwhile in the R
> "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.
On Fri, 2011-04-15 at 08:54 -0600, Tom Tromey wrote:
> 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.
Interesting, I didn't know that. Note that the version of binutils
readelf on fedora doe
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
On Fri, Apr 15, 2011 at 03:26, Mark Wielaard wrote:
> How does GNU standardization work BTW?
It works by all the relevant people agreeing about keeping things
stable and ideally writing it up in a form which a) can be looked up
by others (perhaps for re-implementation) and b) so they can be held
Hi Roland,
> I'm dubious about this. The .gdb_index format is not
> standardized even in the GNU sense.
How does GNU standardization work BTW?
Is there some GNU tools list?
> It's entirely gdb's private business. Unless and until
> it becomes a standard thing that an elfutils tool could generate
I'm dubious about this. The .gdb_index format is not standardized even in
the GNU sense. It's entirely gdb's private business. Unless and until it
becomes a standard thing that an elfutils tool could generate itself by
well-specified rules not involving language-specific knowledge, I think
this
Hi,
In Fedora 15 debuginfo files have a new section .gdb_index.
This patch adds support for printing it out with readelf.
2011-04-14 Mark Wielaard
* readelf.c (options): Add gdb_index.
(section_e): Define section_gdb_index.
(parse_opt): Recognize gdb_index debug-dump argument.
33 matches
Mail list logo
