Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Yao Qi <yao@codesourcery.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: Fri, 04 May 2012 17:58:00 -0000	[thread overview]
Message-ID: <20120504175830.GQ15555@adacore.com> (raw)
In-Reply-To: <4FA22D7B.1040707@codesourcery.com>

> I am not sure we can call this an "error" in GCC, especially it is used
> for some years.  The ABI of different arch may overwrite some rules in
> general ABI, like tic6x in this case.

I guess that depends, but let's not argue over this.

> I don't know how debug info helps here.  In fact, the patch is more
> about "argument passing" rather than "value return".  On some arch,
> function "s.substr(0,4)" expects three parameters "this", "0", and "4",
> while other some other arch, it expects four, "return location", "this",
> "0", and "4".

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).

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.

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?

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.

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.

-- 
Joel


  reply	other threads:[~2012-05-04 17:58 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 [this message]
2012-05-07  3:39       ` Yao Qi
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=20120504175830.GQ15555@adacore.com \
    --to=brobecker@adacore.com \
    --cc=cltang@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=yao@codesourcery.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