On 07/18/2017 11:30 PM, Pedro Alves wrote:
> On 07/18/2017 09:14 PM, Keith Seitz wrote:
>> On 06/02/2017 05:22 AM, Pedro Alves wrote:
>> I'm seeing regressions with this patch (no subsequent patch seems to fix it, either):
>>
I setup a F21 VM w/ gcc-gnat-4.9, and was able to reproduce them.
The problem was that there were some code paths that would
result in GDB Ada-encoding an already-encoded name.
Looking at https://sourceware.org/bugzilla/show_bug.cgi?id=12607 I
realized that my "progression" was really a sign of a regression,
and the cause was the same (the resolve_subexp hunk below).
Below's the patch on top of patch #25 that fixes the regressions.
It's the same as you've tested, only cleaned up a little. Thanks
much for noticing this, and for testing the earlier patch too.
I'll send the updated patch #25 as a reply.
From 5fe82c63f79a3600247f8cd73540eac28e8a0b13 Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Thu, 20 Jul 2017 12:01:50 +0100
Subject: [PATCH] Fix regressions seen with gcc-gnat-4.9 on F21
---
gdb/ada-lang.c | 30 ++++++++++++++++++++----------
1 file changed, 20 insertions(+), 10 deletions(-)
@@ -3579,7 +3579,7 @@ resolve_subexp (struct expression **expp, int *pos, int deprocedure_p,
int n_candidates;
n_candidates =
- ada_lookup_symbol_list (ada_encode (ada_decoded_op_name (op)),
+ ada_lookup_symbol_list (ada_decoded_op_name (op),
(struct block *) NULL, VAR_DOMAIN,
&candidates);
i = ada_resolve_function (candidates, n_candidates, argvec, nargs,
@@ -5661,7 +5661,6 @@ add_nonlocal_symbols (struct obstack *obstackp,
memset (&data, 0, sizeof data);
data.obstackp = obstackp;
- const char *name = ada_lookup_name (lookup_name);
bool is_wild_match = lookup_name.ada ().wild_match_p ();
ALL_OBJFILES (objfile)
@@ -5669,12 +5668,14 @@ add_nonlocal_symbols (struct obstack *obstackp,
data.objfile = objfile;
if (is_wild_match)
- objfile->sf->qf->map_matching_symbols (objfile, name, domain, global,
+ objfile->sf->qf->map_matching_symbols (objfile, lookup_name.name ().c_str (),
+ domain, global,
aux_add_nonlocal_symbols, &data,
symbol_name_match_type::WILD,
NULL);
else
- objfile->sf->qf->map_matching_symbols (objfile, name, domain, global,
+ objfile->sf->qf->map_matching_symbols (objfile, lookup_name.name ().c_str (),
+ domain, global,
aux_add_nonlocal_symbols, &data,
symbol_name_match_type::FULL,
compare_names);
@@ -5692,14 +5693,14 @@ add_nonlocal_symbols (struct obstack *obstackp,
if (num_defns_collected (obstackp) == 0 && global && !is_wild_match)
{
+ const char *name = ada_lookup_name (lookup_name);
+ std::string name1 = std::string ("<_ada_") + name + '>';
+
ALL_OBJFILES (objfile)
{
- char *name1 = (char *) alloca (strlen (name) + sizeof ("_ada_"));
- strcpy (name1, "_ada_");
- strcpy (name1 + sizeof ("_ada_") - 1, name);
data.objfile = objfile;
- objfile->sf->qf->map_matching_symbols (objfile, name1, domain,
- global,
+ objfile->sf->qf->map_matching_symbols (objfile, name1.c_str (),
+ domain, global,
aux_add_nonlocal_symbols,
&data,
symbol_name_match_type::FULL,
@@ -5888,10 +5889,19 @@ ada_lookup_encoded_symbol (const char *name, const struct block *block,
struct block_symbol *candidates;
int n_candidates;
+ /* Since we already have an encoded name, wrap it in '<>' to force a
+ verbatim match. Otherwise, if the name happens to not look like
+ an encoded name (because it doesn't include a "__"),
+ ada_lookup_name_info would re-encode/fold it again, and that
+ would e.g., incorrectly lowercase object renaming names like
+ "R28b" -> "r28b". */
+ std::string verbatim = std::string ("<") + name + '>';
+
gdb_assert (info != NULL);
memset (info, 0, sizeof (struct block_symbol));
- n_candidates = ada_lookup_symbol_list (name, block, domain, &candidates);
+ n_candidates = ada_lookup_symbol_list (verbatim.c_str (), block,
+ domain, &candidates);
if (n_candidates == 0)
return;