From: Tom Tromey <tom@tromey.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: Jonah Graham <jonah@kichwacoders.com>,
Simon Marchi <simark@simark.ca>, Tom Tromey <tom@tromey.com>,
gdb-patches@sourceware.org
Subject: Re: Propose we release GDB 9.1 next weekend (Feb 01-02)
Date: Wed, 05 Feb 2020 10:08:00 -0000 [thread overview]
Message-ID: <87blqdgxd2.fsf@tromey.com> (raw)
In-Reply-To: <20200201130634.GA3103@adacore.com> (Joel Brobecker's message of "Sat, 1 Feb 2020 17:06:34 +0400")
>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:
Joel> FWIW, in terms of reverting, I was only thinking of reverting
Joel> in the gdb-9-branch.
I sent a reversion patch. It's pretty straightforward, but take a quick
look anyway.
Joel> It's possible we might decide to revert
Joel> in master as well, but, at the moment, it's looking like we have
Joel> a decent chance of fixing the issue in master withing a reasonable
Joel> time frame. So I'm not advocating for a revert in master just yet.
Joel> Open to people's thoughts, though, as always!
I wasn't sure what to do here, either.
For trunk I think we should at least have a regression test for the
bug exposed in PR breakpoints/24915.
I suppose right now the name to search by and the name to display are
entangled in the code. So maybe another approach to fixing the original
problem would be to untangle them somehow. I recall wanting to move
this information into the source cache, and out of the symtabs; but I
looked at this and it was a little complicated because, IIRC, the search
can depend on the path to the objfile. Maybe we could have a unified
table per objfile though, the idea being to consolidate and cache the
lookups, so that (1) it's shared across symtabs and psymtabs, and (2)
things like the name to print can be computed lazily if possible.
Hopefully this makes sense,
Tom
next prev parent reply other threads:[~2020-02-05 10:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-26 15:41 Joel Brobecker
2020-01-26 16:07 ` Eli Zaretskii
2020-01-28 16:43 ` Nick Alcock
2020-01-28 17:06 ` Hannes Domani via gdb-patches
[not found] ` <ee83b6c0-8e18-eb1e-18c8-f9df79b547d7@simark.ca>
2020-01-28 17:37 ` Hannes Domani via gdb-patches
2020-02-01 3:20 ` Jonah Graham
2020-02-01 8:00 ` Simon Marchi
2020-02-01 12:17 ` Joel Brobecker
2020-02-01 12:58 ` Jonah Graham
2020-02-01 13:06 ` Joel Brobecker
2020-02-05 10:08 ` Tom Tromey [this message]
2020-02-01 15:45 ` Simon Marchi
2020-02-01 15:37 ` Simon Marchi
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=87blqdgxd2.fsf@tromey.com \
--to=tom@tromey.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=jonah@kichwacoders.com \
--cc=simark@simark.ca \
/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