From: Tom Tromey <tromey@redhat.com>
To: Keith Seitz <keiths@redhat.com>
Cc: Jan Kratochvil <jan.kratochvil@redhat.com>, gdb-patches@sourceware.org
Subject: Re: [rfc] physname cross-check [Re: [RFA] Typedef'd method parameters [0/4]]
Date: Tue, 17 May 2011 21:01:00 -0000 [thread overview]
Message-ID: <m3boz1dosz.fsf@fleche.redhat.com> (raw)
In-Reply-To: <4DD2BB36.5000704@redhat.com> (Keith Seitz's message of "Tue, 17 May 2011 11:15:18 -0700")
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
next prev parent reply other threads:[~2011-05-17 21:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-21 21:15 [RFA] Typedef'd method parameters [0/4] Keith Seitz
2011-04-25 20:53 ` Tom Tromey
2011-05-12 21:28 ` Keith Seitz
2011-05-16 15:49 ` [rfc] physname cross-check [Re: [RFA] Typedef'd method parameters [0/4]] Jan Kratochvil
2011-05-17 18:15 ` Keith Seitz
2011-05-17 18:33 ` Jan Kratochvil
2011-05-17 19:04 ` Keith Seitz
2011-05-17 21:01 ` Tom Tromey [this message]
2011-05-19 23:04 ` [rfc] physname cross-check #2 Jan Kratochvil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3boz1dosz.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=keiths@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox