From: Joel Brobecker <brobecker@adacore.com>
To: Pedro Alves <palves@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC] regresssion(internal-error) printing subprogram argument
Date: Fri, 26 Jan 2018 04:50:00 -0000 [thread overview]
Message-ID: <20180126045047.qy3q5efr3trlpfkv@adacore.com> (raw)
In-Reply-To: <20180117091332.z7bqu4aljudq33sw@adacore.com>
[-- Attachment #1: Type: text/plain, Size: 2831 bytes --]
> > I'm curious to know if after all the fixing you still see
> > the KFAIL on your end. I get:
> >
> > KPASS: gdb.ada/maint_with_ada.exp: maintenance check-psymtabs (PRMS gdb/22670)
>
> Strange, I still get the error:
>
> (gdb) maintenance check-psymtabs
> Global symbol `interfaces__cS' only found in /[...]/gdb.ada/maint_with_ada/b~var_arr_typedef.adb psymtab
> (gdb) KFAIL: gdb.ada/maint_with_ada.exp: maintenance check-psymtabs (PRMS: gdb/22670)
For the sake of this investigation, I used a simpler program:
| $ cat a.adb
| procedure A is
| begin
| null;
| end A;
The symbol in question is declared in b~a.ads as follow:
| u00045 : constant Version_32 := 16#f60287af#;
| pragma Export (C, u00045, "interfaces__cS");
The debugging information for this variable looks like this:
| <1><a9f>: Abbrev Number: 35 (DW_TAG_variable)
| <aa0> DW_AT_name : (indirect string, offset: 0x3fd): ada_main__u00045
| <aa4> DW_AT_decl_file : 5
| <aa5> DW_AT_decl_line : 128
| <aa6> DW_AT_linkage_name: (indirect string, offset: 0x198c): interfaces__cS
| <aaa> DW_AT_type : <0x79>
| <aae> DW_AT_external : 1
| <aae> DW_AT_location : 9 byte block: 3 80 e5 41 0 0 0 0 0 (DW_OP_addr: 41e580)
The important bit is that it has a DW_AT_linkage_name attribute.
When we look at dwarf2read.c::new_symbol, we can see:
| /* Cache this symbol's name and the name's demangled form (if any). */
| SYMBOL_SET_LANGUAGE (sym, cu->language, &objfile->objfile_obstack);
| linkagename = dwarf2_physname (name, die, cu);
| SYMBOL_SET_NAMES (sym, linkagename, strlen (linkagename), 0, objfile);
In our case, LINKAGENAMES is "interfaces(char, signed)"; as you
intuitively guessed, C++ demangling was applied on the symbol.
Following that thread and looking at dwarf2_physname, we see that
it basically calls gdb_demangle, and that works, then returns
its value as the physname.
Continuing on, gdb_demangle is just a wrapper for bfd_demangle,
and neither take any language information as a parameter. And
looking at bfd_demangle I found that it is just a wrapper around
cplus_demangle. Since Ada does not follow the same encoding
technique, this should not be done for Ada symbols.
Attached is a prototype patch which hacks that idea into the current
code. It was tested on x86_64-linux, and both fixes the KFAIL and
shows no regression. I don't understand the command regarding go;
it was just a convenient location for adding the condition.
The part that worries me is that we have several other other locations
where gdb_demangle is being called. Half of them are from language-
specific areas, so probably not an issue for Ada. But I think I will
review the other ones...
To be continued. Thoughts?
--
Joel
[-- Attachment #2: 0001-WIP-dwarf2read.c-dwarf2_physname-do-not-call-gdb_dem.patch --]
[-- Type: text/x-diff, Size: 883 bytes --]
From d98976141c88b05f414bc8975ee2d77e3e655708 Mon Sep 17 00:00:00 2001
From: Joel Brobecker <brobecker@adacore.com>
Date: Thu, 25 Jan 2018 23:23:54 -0500
Subject: [PATCH] WIP: dwarf2read.c::dwarf2_physname: do not call gdb_demangle
with Ada symbols
---
gdb/dwarf2read.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index 96026a8..dfed170 100644
--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -11127,7 +11127,7 @@ dwarf2_physname (const char *name, struct die_info *die, struct dwarf2_cu *cu)
variant `long name(params)' does not have the proper inferior type.
*/
- if (cu->language == language_go)
+ if (cu->language == language_go || cu->language == language_ada)
{
/* This is a lie, but we already lie to the caller new_symbol.
new_symbol assumes we return the mangled name.
--
2.1.4
next prev parent reply other threads:[~2018-01-26 4:50 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-13 10:37 Joel Brobecker
2017-12-14 19:02 ` Pedro Alves
2017-12-14 19:41 ` Pedro Alves
2017-12-15 9:48 ` Joel Brobecker
2017-12-15 11:02 ` Pedro Alves
2017-12-15 18:57 ` Pedro Alves
2018-01-03 4:33 ` Joel Brobecker
2018-01-04 9:48 ` Joel Brobecker
2018-01-04 12:39 ` Pedro Alves
2018-01-05 16:28 ` Pedro Alves
2018-01-16 11:54 ` Pedro Alves
2018-01-17 9:13 ` Joel Brobecker
2018-01-26 3:51 ` Joel Brobecker
2018-01-26 11:28 ` Pedro Alves
2018-01-29 10:38 ` Joel Brobecker
[not found] ` <250976c6-6e7a-6a8e-b9f2-a57f5b92b965@redhat.com>
2018-01-30 3:56 ` Joel Brobecker
2018-02-05 9:57 ` Joel Brobecker
2018-02-09 9:09 ` [RFA/RFC] fix PR gdb/22670 (pb looking up some symbols when they have a linkage name) (was: "Re: [RFC] regresssion(internal-error) printing subprogram argument") Joel Brobecker
2018-02-21 3:02 ` PING: " Joel Brobecker
2018-03-19 21:22 ` PING^2: " Joel Brobecker
2018-03-26 14:26 ` PING^2: [RFA/RFC] fix PR gdb/22670 (pb looking up some symbols when they have a linkage name) Pedro Alves
2018-03-27 14:02 ` Joel Brobecker
2018-01-26 4:50 ` Joel Brobecker [this message]
2017-12-15 18:31 ` [RFC] regresssion(internal-error) printing subprogram argument Pedro Alves
2017-12-15 7:54 ` Joel Brobecker
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=20180126045047.qy3q5efr3trlpfkv@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@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