On 2012/06/01 17:58:41, saugustine wrote:
The enclosed patch updates the earlier patch to address all of the
feedback I
have gotten regarding generating pubnames. It fixes the offset problem
in
the pubtypes table; switches DW_AT_pubtypes to a flag and so on.
It also adds and documents a ne
On 05/30/2012 01:52 PM, Cary Coutant wrote:
At the time we emit the pubtypes table, we have a pointer to the DIE
I can add a field to the comdat_type_node structure to keep track of
the skeleton DIE for a given type unit, so that I can easily get the
right DIE offset for cases where there is a s
> At the time we emit the pubtypes table, we have a pointer to the DIE
> that has been moved to the type unit, and there's no mapping from that
> back to the skeleton DIE. As it stands, we don't even emit a skeleton
> DIE unless one of its descendants is a declaration, so we can't count
> on always
>>> 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
>>> anythin
On Tue, May 22, 2012 at 01:04:15PM -0700, Cary Coutant wrote:
> That might be workable. Let me take a look at the gold changes I'd
> need to make for that.
>
> They don't have to be relocations, though -- since they're only used
> by the linker, a raw section-relative offset would be sufficient.
> 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.
Right. I also need to rea
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 id
> I would expect the linker to start by processing the pubnames/pubtypes
> sections, and then if it wants to look through the CUs as well it already
> knows which ones it can skip.
>
> The presence or absence of an attribute seems like a fragile way to
> determine whether or not particular debug in
On Tue, May 22, 2012 at 10:19 AM, Jason Merrill wrote:
I'll let Cary handle the other questions.
> Yes, I agree that we want to put "some_function" in pubnames. I still don't
> see how putting the anonymous namespace itself in pubnames helps at all. As
> far as pubnames is concerned, the anony
On 05/21/2012 02:39 PM, Cary Coutant wrote:
The DW_AT_GNU_pubnames/pubtypes attributes serve two purposes: (1)
they let the linker know which CUs have pubnames & pubtypes sections,
and (2) they let us know that the pubnames and pubtypes are "reliable"
(relative to the incomplete sections that GCC
>> The entire motivation for this patch, including the proposed new
>> attributes is at:
>>
>> http://gcc.gnu.org/wiki/DebugFission
>>
>> In particular, the section titled, "Building a GDB Index".
>
> OK, I've read that section and I still don't understand why the consumer
> would need a pointer fr
On 05/18/2012 07:34 PM, saugust...@google.com wrote:
The motivation and new dwarf attributes and tags all stem from the debug
fission project as described at http://gcc.gnu.org/wiki/DebugFission.
Right. Not sure why I missed the pubtypes bits on that page before...
The code I removed doesn't
Hi Jasaon,
Thanks so much for reviewing this patch. I realize it is a lot to see.
The motivation and new dwarf attributes and tags all stem from the debug
fission project as described at http://gcc.gnu.org/wiki/DebugFission. I
have several more patches dealing with fission coming.
Fission has b
This patch makes a lot of changes to the behavior of .debug_pubnames
that I haven't seen any discussion of, and that don't seem obvious to
me. Can you point me at discussion threads?
http://codereview.appspot.com/6197069/diff/1/gcc/dwarf2out.c
File gcc/dwarf2out.c (left):
http://codereview.app
14 matches
Mail list logo
