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: [rfc] physname cross-check [Re: [RFA] Typedef'd method parameters [0/4]]


On 05/16/2011 08:48 AM, Jan Kratochvil wrote:

I wrote a cross-check of what GDB thinks is the physname (which is in
demangled canonical form) vs. what GCC thinkgs is the physname (which needs to
be converted from mangled form and canonicalized).

That's a great idea! "Why didn't I think of that?" (famous last words)


It reports for me 34524 unique failures on libwebkit.so.debug.  (Sure such
count is caused only by a few physname computation bugs.)

I will start looking into these and filing/fixing bugs when my plate opens up here in the next day or two.


Therefore I would propose a sinful idea to temporarily just use
DW_AT_linkage_name if it is available to ever release gdb-7.3 and make
DW_AT_linkage_name-less GDB a feature for gdb-7.4.  After all such cross-check
should exist anyway for verifying both GCC and GDB bugs this way.

For me, what really matters is what is best for users. Is reverting dwarf2_physname better or worse than DW_AT_MIPS_linkage_name? That's a difficult question to answer in a black-and-white way, really, but my instincts (which could be wrong, of course) tell me that MIPS_linkage_name is the greater of two evils.


cat>1.h<<EOH
struct x {};
class C { public: void m (x *xp); };
EOH
cat>1.C<<EOH
#include "1.h"
C c;
int main () { c.m(0); }
EOH
cat>1b.C<<EOH
#include "1.h"
void C::m (x *xp) {}
EOH

I've fixed this bug. This was just introduced in this patchset because the typeprinter did not recognize that in C++, "struct" = "class". [To be clear, it was *my* patch which introduced this inequality.] I have fixed this my patchset, and I have added a test for it.


Unfortunately, I must reiterate that I am a slave to the test suite. While I try my best to test everything that comes to mind, ultimately, not everything comes to (my) mind.

Just it has some other existing testsuite regressions:
	gdb.cp/bs15503.exp gdb.cp/cp-relocate.exp gdb.cp/cpexprs.exp
	gdb.java/jmisc.exp gdb.java/jprint.exp

Using DW_AT_MIPS_linkage_name will not pass cpexprs.exp without some hacking; the demangled name will need to be re-parsed (to remove typedefs -- that might be a bit easier with this patchset) and subsequently canonicalize the result.


I really see this as an even bigger risk than keeping the current code. And then there's constructors -- no version of GCC that I've seen outputs DW_AT_MIPS_linkage_name for ctors, so they would still have to be computed in some way.

What do you think?

In the end, it probably doesn't really matter what I think. :-) IMO, this all boils down to risk management. Which path is least risky for users and most conducive to moving forward?


This is a decision for you and other maintainers to consider.

Keith


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