This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Dwarf Patch] Improve pubnames and pubtypes generation. (issue 6197069)


On 05/22/2012 01:27 PM, Sterling Augustine wrote:
Anonymous namespaces are funky in general, but gdb would like to be
able to do things like tab completion on:

(gdb) b '(anonymous namespace)::
(gdb) b 'foo::(anonymous namespace)::

Without being able to lookup anonymous namespaces, gdb has no idea
where to continue from.

Ah. I guess that makes sense.


On 05/22/2012 01:49 PM, Cary Coutant wrote:
In the context of Tom's original suggestion to add .gdb_index, I
suggested fixing the problems with .debug_pubnames and using the
producer string to distinguish. Tom had several objections to the use
of the producer string for that:

http://sourceware.org/ml/archer/2009-q4/msg00065.html

Sure, his point about backporting patches is a strong argument.


I'm simply trying to do something that's fairly simple and that works.
These attributes are GNU extensions, and I do not intend to propose
these as part of the DWARF 5 standard -- they're stopgap measures
until we have a better plan for accelerated lookup tables.

Starting with the pubnames sections then going back and reading the
debug_info sections would require an extra table and a lookup for each
CU to see if it's already been covered by a pubnames section.

Yes, but I would expect this table lookup to be faster than going to the disk to read the CU DIE and abbrev in order to check for the attribute. OTOH, I suppose you need to read it anyway if you want to check somehow whether you should trust the pub* information.


Building
the .gdb_index in gold is still too slow, but these attributes help
make it a bit faster than it was without them.

Are these two attributes a showstopper issue for you?

No, I'm just reluctant to add more relocations. Could we make them just flags?


Hmm.  Looking at the code, it seems that the pubtypes entries for these
types will point to the main CU, but with the offset in the type_unit, so a
consumer trying to follow the pointer will find garbage.  If you want to
have a pubtypes entry, it needs to point to a type skeleton to avoid
crashing standard-conforming consumers.

Yes, I understand that's broken, but there are no consumers at this point that make any use of that offset. Would it be acceptable if we just put 0 there? (Given that I expect .debug_pub* to go away soon, I don't think it's worth the trouble of filling in the offset with anything more meaningful.)

I wouldn't expect it to be much harder to put the skeleton there than plain 0.


Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]