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]]


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

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

I can put aside what I am doing and help out with this.  Can you push a
branch with your patches, and Jan's checking patch, to archer.git?  We
can split up the problems and work on them.

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

Keith> For me, what really matters is what is best for users. Is reverting
Keith> dwarf2_physname better or worse than DW_AT_MIPS_linkage_name?

I think either answer has some bad qualities, even if you just consider
the 7.3 release.

With Jan's proposal we are basically going back to the state before
physname.  As Keith points out, this regresses a good chunk of the new
tests that went in with physname.

Keeping physname means further delaying 7.3 and probably accepting that
we will have more as-yet-unknown regressions.

I don't have a good basis on which to evaluate the evidence pro or con.
My default position is to try push forward, not back: fix the bugs in
physname.

If there is more evidence for or against either approach, I would love
to know it.

Jan> What do you think?

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

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

No fair trying to escape.  And, your opinion does matter.

Tom


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