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 mjw@redhat.com
* readelf.c (options): Add gdb_index. (section_e): Define section_gdb_index. (parse_opt): Recognize gdb_index debug-dump argument. (print_gdb_index_section): New function. (print_debug): Add gdb_index to debug_sections.
Sample output looks like:
GDB section [34] '.gdb_index' at offset 0x722c contains 9235 bytes : Version: 4 CU offset: 0x18 TU offset: 0x58 address offset: 0x58 symbol offset: 0xbc constant offset: 0x20bc
CU list at offset 0x18 contains 4 entries: [ 0] start: 00000000, length: 5022 [ 1] start: 0x00139e, length: 3166 [ 2] start: 0x001ffc, length: 1320 [ 3] start: 0x002524, length: 1529
TU list at offset 0x58 contains 0 entries:
Address list at offset 0x58 contains 5 entries: [ 0] 0x0000000008048ad0 <main>..0x0000000008048d94 <main+0x2c4>, CU index: 0 [ 1] 0x0000000008048e50 <create_regexp>..0x0000000008049ad8 <jargrep+0x998>, CU index: 0 [ 2] 0x0000000008049ae0 <report_str_error>..0x000000000804a9fa <inflate_string+0x25a>, CU index: 1 [ 3] 0x000000000804aa10 <pb_init>..0x000000000804ac29 <pb_read+0x149>, CU index: 2 [ 4] 0x000000000804ac30 <shift_up>..0x000000000804aff3 <shift_down+0x1f3>, CU index: 3
Symbol table at offset 0x58 contains 1024 slots: [ 2] symbol: free_func, CUs: 1 [ 5] symbol: size_t, CUs: 0 [ 9] symbol: option, CUs: 0 [ 12] symbol: compress_file, CUs: 1 [ 42] symbol: pb_read, CUs: 2 [ 52] symbol: short unsigned int, CUs: 0 [ 68] symbol: unsigned char, CUs: 0 [ 78] symbol: _IO_FILE, CUs: 0 [...]
Does this look OK to add?
Patch attached and on the mjw/gdb_index git branch.
Thanks,
Mark
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 belongs in its own gdb-specific tool.
Thanks, Roland
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 itself by well-specified rules not involving language-specific knowledge, I think this belongs in its own gdb-specific tool.
I don't think it involves any language-specific knowledge. And although the documentation is somewhat hidden (see the comment in the patch where to find it). I could write this just by going from the documentation.
On the one hand I agree, it is a somewhat odd section. And I was actually going to suggest that it gets generated as something separate. Currently it takes up about ~10% of the .debug files.
On the other hand, it is kind of standard now, and is part of the standard elf sections even we already recognize in ebl. Which means tools like eu-strip for example already handle it specially. And since it does take up so much space in the standard separate debuginfo files it makes sense to want to inspect it. It is also properly versioned, so we can recognize whether or not we can parse it. And seeing it is so big, we really should look into either making it work with other tools, or look at what it provides gdb, so we can improve the standard indexes to make other tools also benefit.
What about a compromise? We don't print is by default with -w/--dump-debug, but only when explicitly requested?
diff --git a/src/readelf.c b/src/readelf.c index 7250bb3..f4b427e 100644 --- a/src/readelf.c +++ b/src/readelf.c @@ -189,11 +189,12 @@ static enum section_e section_macinfo = 256, /* .debug_macinfo */ section_ranges = 512, /* .debug_ranges */ section_exception = 1024, /* .eh_frame & al. */ - section_gdb_index = 2048, /* .gdb_index */ + section_gdb_index = 2048, /* .gdb_index, like a .debug section, + but not printed by default. */ section_all = (section_abbrev | section_aranges | section_frame | section_info | section_line | section_loc | section_pubnames | section_str | section_macinfo - | section_ranges | section_exception | section_gdb_index) + | section_ranges | section_exception) } print_debug_sections, implicit_debug_sections;
/* Select hex dumping of sections. */
Thanks,
Mark
On Fri, Apr 15, 2011 at 03:26, Mark Wielaard mjw@redhat.com 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 accountable for incompatible changes.
Roland's point was that this is so far only something that is local to gdb where no code outside gdb needs to know anything about the format of the section. Therefore the gdb people can change it whenever they'd like. This in not an unreasonable position since aside from this possible readelf decoder really nothing needs that data and therefore any type of "standardization" can only lead to unnecessary complications. The best solution in that case is to have gdb provide the decoder.
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
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 doesn't support it atm, but binutils trunk does.
The output seems to match that of eu-readelf --debug-dump=gdb_index, so at least I understood the format just like binutils does. I like the eu-readelf output a little better, but that is mainly because I wrote it. But one advantage is that in the address table all addresses are printed with matching symbols whenever possible.
Do you think it makes sense to support printing this format, or will you be arbitrarily changing it from time to time? Having it more prominently documented would be nice.
It looks to me we would like to support it for other tools, or at least figure out what the deficiencies were with the other dwarf indexes so we can improve them to make them more useful to other dwarf consumers.
Thanks,
Mark
"Mark" == Mark Wielaard mjw@redhat.com 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. Where would you suggest?
Mark> It looks to me we would like to support it for other tools, or at least Mark> figure out what the deficiencies were with the other dwarf indexes so we Mark> can improve them to make them more useful to other dwarf consumers.
There are 3 indices in DWARF. AFAIK .debug_aranges doesn't really have problems, except one theoretical one that everybody has agreed to ignore. I'm not sure why I didn't just use this instead of putting the ranges into .gdb_index; maybe I was too worried about this theoretical problem. (Changing this might be a decent way to shrink .gdb_index.)
The other indices have these problems, at least from the GDB POV:
* GCC had a number of historical bugs in .debug_pubnames generation. It did not handle qualified names correctly. Some names were missing.
To me this means it is unreliable -- even if it exists, how would GDB know to trust it?
* .debug_pubnames only lists public names. This is insufficient; gdb users are used to typing `break unique_static_function' at startup. This problem may apply to .debug_pubtypes as well.
* Names are not canonicalized. To make GDB's symbol tables work properly, it has to canonicalize C++ names. Doing this while reading .debug_pubnames is too slow. The names in .gdb_index are run through the canonicalizer.
IIRC, I did some tests where I:
* Changed GCC to generate .debug_priv{names,types} as well * Disabled canonicalization in GDB
... and these sections were still too slow to read. All the data is somewhere in the Archer archives.
Anyway, the nice thing about .gdb_index is we can just mmap it.
Maybe I was too hasty; the indices could probably be read in a background thread or something like that. I don't think I seriously considered this at the time.
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 RPM case. If instead the compiler emitting indices that were then somehow more usable (e.g., linker makes the hash table), it would be better. AFAIK nobody is working on this.
We've also discussed proposing this as a DWARF standard. However, DWARF is hard to work with, and writing this up as a standard would be a pain, mostly due to having to explain the details of name canonicalization. I suppose we could revisit this.
Tom
On Fri, Apr 15, 2011 at 12:18, Tom Tromey tromey@redhat.com 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 RPM case. If instead the compiler emitting indices that were then somehow more usable (e.g., linker makes the hash table), it would be better. AFAIK nobody is working on this.
We've also discussed proposing this as a DWARF standard. However, DWARF is hard to work with, and writing this up as a standard would be a pain, mostly due to having to explain the details of name canonicalization. I suppose we could revisit this.
The linker is IMO the right place.
What this means it is far too early to add any output routines anywhere.
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 current documentation is fine, it should just be moved to a more easily discoverable location.
There are 3 indices in DWARF. AFAIK .debug_aranges doesn't really have problems, except one theoretical one that everybody has agreed to ignore. I'm not sure why I didn't just use this instead of putting the ranges into .gdb_index; maybe I was too worried about this theoretical problem. (Changing this might be a decent way to shrink .gdb_index.)
What is the theoretical problem?
The other indices have these problems, at least from the GDB POV:
- GCC had a number of historical bugs in .debug_pubnames generation.
It did not handle qualified names correctly. Some names were missing.
To me this means it is unreliable -- even if it exists, how would GDB know to trust it?
That is a problem indeed. But since you are (at least currently) relying on "post processing" anyway, we could add a check to dwarflint and somehow mark the file as "complete". This could even be added as a flag in your .gdb_index header ".debug_pubnames: OK". Or we could fixup .debug_pubnames instead of adding a new/duplicate list.
- .debug_pubnames only lists public names. This is insufficient; gdb
users are used to typing `break unique_static_function' at startup. This problem may apply to .debug_pubtypes as well.
OK. That is clearly a deficiency of the current "pub" indexes. Maybe add/propose a standardized .debug_priv variant?
- Names are not canonicalized. To make GDB's symbol tables work
properly, it has to canonicalize C++ names. Doing this while reading .debug_pubnames is too slow. The names in .gdb_index are run through the canonicalizer.
Aha. That is where the language specific part comes in. Is what you are after a quick way to get the scoping/parent namespaces?
IIRC, I did some tests where I:
- Changed GCC to generate .debug_priv{names,types} as well
- Disabled canonicalization in GDB
... and these sections were still too slow to read. All the data is somewhere in the Archer archives.
I'll look that up. I assume this was this thread: http://sourceware.org/ml/archer/2009-q3/threads.html#00105
Anyway, the nice thing about .gdb_index is we can just mmap it.
Maybe I was too hasty; the indices could probably be read in a background thread or something like that. I don't think I seriously considered this at the time.
The reason I stumbled upon this is that I was looking for other ways to compress the debuginfo on fedora. And compared to f14 the packages on f15 are about 10% bigger because of this extra index. If it is part of the actual .debug file then it might be nice to make other consumers also use it (or split it if it really is only for gdb private usage).
Cheers,
Mark
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> ignore. I'm not sure why I didn't just use this instead of putting the Tom> ranges into .gdb_index; maybe I was too worried about this theoretical Tom> problem. (Changing this might be a decent way to shrink .gdb_index.)
Mark> What is the theoretical problem?
There is no way to distinguish between a CU that does not have a corresponding .debug_aranges entry, and a CU that simply has no addresses to represent. This is ambiguous because .debug_aranges is an optional section.
This is semi-pathological, and anyway I think we all agreed to just ignore it.
Tom> * Names are not canonicalized. To make GDB's symbol tables work Tom> properly, it has to canonicalize C++ names. Doing this while reading Tom> .debug_pubnames is too slow. The names in .gdb_index are run through Tom> the canonicalizer.
Mark> Aha. That is where the language specific part comes in. Mark> Is what you are after a quick way to get the scoping/parent Mark> namespaces?
In C++ there are multiple valid ways to write a name. For GDB's purposes, though, it is best if (1) there is only one way to write a name (since GDB has a flat global symbol table -- that is, overloads are stored according to their full name), and (2) if there is a way to also canonicalize user input according to the same rule.
Arguably it is better to fix this in GDB by changing how symbols are stored.
Mark> I'll look that up. I assume this was this thread: Mark> http://sourceware.org/ml/archer/2009-q3/threads.html#00105
Yeah, also "Initial psymtab replacement results" from December 2009. And maybe "gdb index performance" from June 2010.
I couldn't quickly find the message where I posted the performance data using .debug_pub*, sorry.
Tom
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 into .gdb_index; maybe I was too worried about this theoretical Tom> problem. (Changing this might be a decent way to shrink .gdb_index.)
Mark> What is the theoretical problem?
There is no way to distinguish between a CU that does not have a corresponding .debug_aranges entry, and a CU that simply has no addresses to represent. This is ambiguous because .debug_aranges is an optional section.
This is semi-pathological, and anyway I think we all agreed to just ignore it.
I recently made a change to what gcc outputs for an "address less" CU: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02286.html Such a CU will not have a low_pc attribute. Maybe that helps?
Cheers,
Mark
"Mark" == Mark Wielaard mjw@redhat.com 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-pathological, and anyway I think we all agreed to just Tom> ignore it.
Mark> I recently made a change to what gcc outputs for an "address less" CU: Mark> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02286.html Mark> Such a CU will not have a low_pc attribute. Maybe that helps?
I'm afraid not. The problem, if there is one, has to do with a missing .debug_aranges entry. That is:
Suppose GDB is reading .debug_aranges. And suppose each time it reads a new entry in aranges, it matches it to some CU in .debug_info.
Now suppose GDB notices that CU 12340 does not have a .debug_aranges entry. What does this mean?
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 in DWARF, I think this cannot be distinguished from a bad tool or bad user action. That is, maybe the user stripped this section from his .o. Or maybe he used some compiler which does not emit .debug_aranges.
FWIW, at one point I filed a GCC bug about this:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42288
Tom
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 in DWARF, I think this cannot be distinguished from a bad tool or bad user action. That is, maybe the user stripped this section from his .o. Or maybe he used some compiler which does not emit .debug_aranges.
Note that libdw relies on .debug_aranges. For example dwarf_addrdie (), which returns the CU DIE containing a given address, just returns NULL if the aranges section isn't there.
Cheers,
Mark
"Mark" == Mark Wielaard mjw@redhat.com 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 has seen it happen in the wild. In practice, a missing .debug_aranges entry means that the CU covers no addresses.
Tom
On Mon, 2011-04-18 at 11:44 -0600, Tom Tromey wrote:
"Mark" == Mark Wielaard mjw@redhat.com 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 has seen it happen in the wild. In practice, a missing .debug_aranges entry means that the CU covers no addresses.
To make this explicit, lets make the dwarflint check more specific in this case. Petr, does the following make sense?
For CUs with no associated code and a new enough gcc this will no longer complain when no aranges section is found when the CU doesn't have low_pc set.
Thanks,
Mark
commit 3f8d455103b378d96d2a99124c1c332e1e28d9bd Author: Mark Wielaard mjw@redhat.com Date: Thu Apr 21 15:00:34 2011 +0200
dwarflint: Only complain about no aranges if CU has low_pc set.
diff --git a/dwarflint/check_debug_info.cc b/dwarflint/check_debug_info.cc index e415fb1..337b12d 100644 --- a/dwarflint/check_debug_info.cc +++ b/dwarflint/check_debug_info.cc @@ -1261,7 +1261,7 @@ check_debug_info_refs::check_debug_info_refs (checkstack &stack, << "unresolved reference to .debug_line table " << pri::hex (it->stmt_list.addr) << '.' << std::endl;
- if (_m_aranges != NULL && !it->has_arange) + if (_m_aranges != NULL && !it->has_arange && it->low_pc != (uint64_t)-1) wr_message (it->head->where, mc_impact_3 | mc_acc_suboptimal | mc_aranges | mc_info) << "no aranges table is associated with this CU." << std::endl;
Mark Wielaard mjw@redhat.com writes:
On Mon, 2011-04-18 at 11:44 -0600, Tom Tromey wrote:
> "Mark" == Mark Wielaard mjw@redhat.com 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 has seen it happen in the wild. In practice, a missing .debug_aranges entry means that the CU covers no addresses.
To make this explicit, lets make the dwarflint check more specific in this case. Petr, does the following make sense?
For CUs with no associated code and a new enough gcc this will no longer complain when no aranges section is found when the CU doesn't have low_pc set.
I'm not sure. I think that having empty arange section is better, because then it's more explicit. But it's all the same in the end, if the absence is reliable and meaningful, so we can do it like you propose.
However, your patch doesn't take into account DW_AT_ranges (I'm not sure these appear at CU DIEs in practice, but it's legal DWARF). How about this?
- if (_m_aranges != NULL && !it->has_arange) + if (_m_aranges != NULL && !it->has_arange + && (it->low_pc != (uint64_t)-1 || !it->range_refs.empty ()))
And this to enable empty ():
diff --git a/dwarflint/addr-record.hh b/dwarflint/addr-record.hh index 4bbd0c5..fe9718a 100644 --- a/dwarflint/addr-record.hh +++ b/dwarflint/addr-record.hh @@ -77,6 +77,7 @@ public: using _super_t::begin; using _super_t::end; using _super_t::push_back; + using _super_t::empty; };
#endif//DWARFLINT_ADDR_RECORD_H
Thanks, PM
commit 3f8d455103b378d96d2a99124c1c332e1e28d9bd Author: Mark Wielaard mjw@redhat.com Date: Thu Apr 21 15:00:34 2011 +0200
dwarflint: Only complain about no aranges if CU has low_pc set.diff --git a/dwarflint/check_debug_info.cc b/dwarflint/check_debug_info.cc index e415fb1..337b12d 100644 --- a/dwarflint/check_debug_info.cc +++ b/dwarflint/check_debug_info.cc @@ -1261,7 +1261,7 @@ check_debug_info_refs::check_debug_info_refs (checkstack &stack, << "unresolved reference to .debug_line table " << pri::hex (it->stmt_list.addr) << '.' << std::endl;
if (_m_aranges != NULL && !it->has_arange)
if (_m_aranges != NULL && !it->has_arange && it->low_pc != (uint64_t)-1) wr_message (it->head->where, mc_impact_3 | mc_acc_suboptimal | mc_aranges | mc_info) << "no aranges table is associated with this CU." << std::endl;
On Thu, 2011-04-21 at 17:11 +0200, Petr Machata wrote:
Mark Wielaard mjw@redhat.com writes:
For CUs with no associated code and a new enough gcc this will no longer complain when no aranges section is found when the CU doesn't have low_pc set.
I'm not sure. I think that having empty arange section is better, because then it's more explicit.
If you and Tom both agree on that, then lets call it a majority and unblock http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42288 There is already a patch, it doesn't take up a huge amount of space (and the number of no-code CUs is normally low anyway) and it makes more people happy because they feel it is more explicit.
Cheers,
Mark
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
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/Index-Section-Format.html I hope that resolves Roland's doubts about the usefulness of parsing/outputting this section with eu-readelf.
It was already useful BTW. We found out gdb was outputting bad/redundant CU indexes by inspecting the output produced by eu-readelf. Which Tom already fixed. http://sourceware.org/ml/gdb-patches/2011-04/msg00224.html
Cheers,
Mark
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 gdb was outputting bad/redundant CU indexes by inspecting the output produced by eu-readelf. Which Tom already fixed. http://sourceware.org/ml/gdb-patches/2011-04/msg00224.html
I never said you shouldn't write something to parse it. Obviously that is useful. I just said it did not belong in eu-readelf.
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 with the objection at all.
I thought the objection was that it wasn't properly specified/standardized yet. Which it now is IMHO.
I never said you shouldn't write something to parse it. Obviously that is useful. I just said it did not belong in eu-readelf.
I guess I could just use binutils readelf then. Pity, since I like the eu-readelf output better to be honest.
Cheers,
Mark
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 tool using libelf and with the output format you like. It's just not part of eu-readelf.
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 don't think it is very convenient to have different tools for this. Why not make it part of eu-readelf, especially when binutils readelf also supports it. The easiest way to do your suggestion would actually be to just copy readelf.c, rename it digelf.c and add the parsing of sections not supported by plain eu-readelf. The reason it is nice to have parsing/printing of actually used elf sections as part of the same tool is that you can then reuse all the normal output conventions, like in this case the address ranges, with or without symbol resolution depending on -N, etc. Next on my list would be the sdt elf notes section, which also IMHO should just be part of the same tool with which you inspect elf files.
Thanks,
Mark
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 pretty-print some "non-interchange" formats, if they are reasonably stable, don't require much eu-readelf uglification?
- FChE
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 reasonably stable yet.
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 reason to think that .gdb_index format is reasonably stable yet.
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?
- FChE
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.
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 without real agreement.
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.
Well. That is why I asked Tom to document it better and more prominently. I don't think it will just disappear over night. And I am willing to maintain it would there ever be alternative variants.
We don't really have a "not super solid yet, but also not really slushy anymore" elf/dwarf tools in elfutils atm. And IMHO it really doesn't make sense to add something like that. eu-readelf really should just grok them all. It seems the only thing we are really arguing about is whether the format has "solidified" enough. Or do you really like to have another tool that handles "somewhat slushy" sections?
To be honest I would like gdb to drop this section. It eats up valuable space that I think we could use better and/or in other ways that make it easier to add other consumers for it. But only by actually supporting it now and working together on it can we achieve that.
Cheers,
Mark
"Mark" == Mark Wielaard mjw@redhat.com 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 together on it can we achieve that.
I'm happy to work together on a better solution. But first, go read all the old threads. It is harder than you might believe. Most other sensible solutions were shot down.
Tom
On Thu, Apr 21, 2011 at 14:15, Frank Ch. Eigler fche@redhat.com 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 used by gdb. The gdb people unilaterally make changes. If gdb cannot read the info in a file it'll ignore it. Versioning all the changes etc is likely not down nor is it important for gdb. You would have to put chains on the gdb people before you can add a decoder in elfutils and I doubt they want that.
"Ulrich" == Ulrich Drepper drepper@gmail.com 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 not down nor is it important for gdb. You would have to Ulrich> put chains on the gdb people before you can add a decoder in elfutils Ulrich> and I doubt they want that.
We do change this in GDB whenever we need to. Jan has a patch ready that will introduce version 5.
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.texinfo).
Tom
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.texinfo).
Thanks. Seems the chains are in place and all changes will be versioned. So I'll like to add the support to readelf now, unless there are actual comments on the implementation of course.
Cheers,
Mark
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 keep that the same i we care about compatibility with binutils.
I we add this then I am willing to keep the format parsing up to date with whatever changes gdb makes. Since I am interested in making sure that the info is eventually also usable by other consumers (or help migrate gdb to other more standard indexes).
Cheers,
Mark
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/msg00179.html http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/doc/gdb.texinfo.diff?cvsroo...
Only the hashing function has changed so it should not matter to eu-readelf.
Thanks, Jan
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@lists.fedorahosted.org
-
Frank Ch. Eigler -
Jan Kratochvil -
Mark Wielaard -
Petr Machata -
Roland McGrath -
Tom Tromey -
Ulrich Drepper