This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB 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: [RFA] dwarf2_physname


On 09/15/2009 06:32 AM, Daniel Jacobowitz wrote:

Oh, I see.  Is there any other differentiation in the ICC output
between the two relevant cases?  Namely bar and baz in:

class foo {
   void bar();
   static void baz(foo*);
};

In this case, the DWARF output looks pretty much as expected. There is only one DIE defining foo::baz, and that is in the class definition. One quirk: the parameter's DW_AT_name is "$01".


I played with this a bit, and it seems that only ctors and dtors have DIEs outside the class definition (ignoring "normal" C functions). However, in every case I tried, ICC does not output DW_AT_artificial for ANY class method's first parameter. Does ICC not use hidden parameter passing to implement method calls? It seems odd that it would do this for ctors/dtors and no other methods.

In any case, once again, DW_AT_name for method formal parameters is also generated ("$02", "$03", etc). It seems that the only time I see a useful DW_AT_name for anything function-like is for the ctor/dtor (all parameters, not just hidden "this") and C functions.

[Anecdote: Every time I run readelf -w on an ICC-generated object, it complains of "Bogus end-of-siblings marker" -- perhaps there are some bytes in the debuginfo (which readelf/gdb cannot read/interpret) which helps mitigate some of these problems?]

 From discussions on the dwarf-discuss list, I've gathered that pretty
much every debugger is full of compiler-specific quirking.  In
practice, to provide a good user experience, we have to interpret the
DWARF in our best understanding of each compiler's intentions rather
than just through the standard.

Sure, that doesn't really surprise me. But these three quirks (conflicting DIEs for same object, missing DW_AT_artificial, nonsensical DW_AT_name) would seem truly unnecessary and fairly trivial to fix.


Of course, that relies on someone wanting to do the work for ICC support.

It may just be useful to provide (yet another) switch to turn on DW_AT_MIPS_linkage_name processing (and disable the proposed physname work). We could do this switch manually (set dwarf-linkage-name on?) and/or by producer (turn it on for ICC by default).


Keith


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