From: Yao Qi <yao@codesourcery.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: <gdb-patches@sourceware.org>, <cltang@codesourcery.com>
Subject: Re: [PATCH 1/4] New gdb arch hook: return_with_first_hidden_param_p
Date: Mon, 07 May 2012 03:39:00 -0000 [thread overview]
Message-ID: <4FA743EC.1080903@codesourcery.com> (raw)
In-Reply-To: <20120504175830.GQ15555@adacore.com>
On 05/05/2012 01:58 AM, Joel Brobecker wrote:
> I'd like to know what the code is, and what the associated debug info
> looks like today. How many parameters would the debug info list for
> your function above when the return value is passed as a hidden
> parameter? I am guessing 4. I am pretty sure that this is what GNAT
> does for Ada (IIRC, GNAT emits a parameter named "TARGET" for it).
>
It is 3, unfortunately. I got the similar debug info output on both x86
and tic6x:
<2><233a>: Abbrev Number: 45 (DW_TAG_subprogram)
<233b> DW_AT_external : 1
<233c> DW_AT_name : (indirect string, offset: 0x1759):
substr
<2340> DW_AT_decl_file : 9
<2341> DW_AT_decl_line : 2004
<2343> DW_AT_MIPS_linkage_name: (indirect string, offset: 0x297d):
_ZNKSs6substrEjj
<2347> DW_AT_type : <0x1160>
<234b> DW_AT_declaration : 1
<234c> DW_AT_sibling : <0x2361>
<3><2350>: Abbrev Number: 15 (DW_TAG_formal_parameter)
<2351> DW_AT_type : <0x2466>
<2355> DW_AT_artificial : 1
<3><2356>: Abbrev Number: 16 (DW_TAG_formal_parameter)
<2357> DW_AT_type : <0x3b>
<3><235b>: Abbrev Number: 16 (DW_TAG_formal_parameter)
<235c> DW_AT_type : <0x3b>
> What debug info could do for us is tag that special parameter
> using an attribute like DW_AT_return_address_as_implicit_param.
> Then we could do have a generic mechanism in GDB that picks it
> up, and calls the function appropriately without having to have
> insider knowledge as to when such parameter is being used.
>
Yes, we need some new tag to describe for this situation.
> I think there is one avenue that needs to be looked at with
> respect to debugging info: Maybe consult with the DWARF committee
> to see how this type of situation is supposed to be handled.
> Perhaps it's already covered?
Yes, it is a good idea to ask in dwarf-discuss@ to see if people there
have some smart ideas. Will do.
>
> Now, I realize that getting the GCC guys to improve the debug
> info might not be easily doable. Perhaps a possible option
> is to identify the special hidden field using some heuristics
> (field name, for instance), and then pretend that this parameter
> had the special DWARF attribute. That way, the day GCC starts
> describing the implict parameters better, it'll just work out
> of the box, and we phase out the hack a few years later.
>
The heuristics in my mind is to do prologue analysis, to see how many
parameters are expected in sub routine, but not sure how reliable and
effective it is.
> I should add that I am badly overloaded these days and I don't
> see it getting better any time soon. It's possible that I am not
> getting what the real problem is simply because I don't know C++
> (I learnt the basics over 15 years ago and haven't used it since).
> Anyone knowing C++ better should feel free to take the discussion
> over.
This problem is caused by C++ argument passing in inf-call, but not a
C++ problem, IMO. Any one here should be able to comment on this patch,
don't be scared by C++ :)
--
Yao (é½å°§)
next prev parent reply other threads:[~2012-05-07 3:39 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-18 13:28 Yao Qi
2012-04-18 13:18 ` [PATCH 4/4] m68k: Install return_with_first_hidden_param_p Yao Qi
2012-05-16 21:01 ` Tom Tromey
2012-04-18 13:18 ` [PATCH 3/4] sh: " Yao Qi
2012-05-16 21:00 ` Tom Tromey
2012-04-18 13:18 ` [PATCH 2/4] tic6x: " Yao Qi
2012-05-16 20:59 ` Tom Tromey
2012-04-25 11:02 ` [PATCH 1/4] New gdb arch hook: return_with_first_hidden_param_p Yao Qi
2012-05-03 0:43 ` [ping 2] : " Yao Qi
2012-05-03 1:15 ` Joel Brobecker
2012-05-03 7:00 ` Yao Qi
2012-05-04 17:58 ` Joel Brobecker
2012-05-07 3:39 ` Yao Qi [this message]
2012-05-07 20:14 ` Joel Brobecker
2012-05-09 8:39 ` Yao Qi
2012-05-10 21:21 ` Joel Brobecker
2012-05-11 10:35 ` Yao Qi
2012-05-14 17:15 ` Joel Brobecker
2012-05-15 6:51 ` Yao Qi
2012-05-15 15:01 ` Joel Brobecker
2012-05-16 1:37 ` Yao Qi
2012-05-16 15:31 ` Joel Brobecker
2012-05-16 21:03 ` Tom Tromey
2012-05-15 18:03 ` Mark Kettenis
2012-05-16 1:55 ` Yao Qi
2012-05-17 21:02 ` Mark Kettenis
2012-07-06 13:17 ` Gary Benson
2012-05-15 15:35 ` Thomas Schwinge
2012-05-15 21:30 ` Joel Brobecker
2012-05-03 14:04 ` Chung-Lin Tang
2012-05-16 20:56 ` Tom Tromey
2012-05-16 23:03 ` Mark Kettenis
2012-06-08 14:30 ` Yao Qi
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=4FA743EC.1080903@codesourcery.com \
--to=yao@codesourcery.com \
--cc=brobecker@adacore.com \
--cc=cltang@codesourcery.com \
--cc=gdb-patches@sourceware.org \
/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