This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/4] New gdb arch hook: return_with_first_hidden_param_p


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]