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

[Joel Brobecker <brobecker@adacore.com>]

> C++ ABI is intended to be cross-architecture, but C++ ABI ends up being
> target-dependent at some points.  In practice, GDB has to know which
> architecture is special.
> 
> As I said above, GCC changes a language-dependent rule to a
> target-dependent rule 'by mistake', so GDB has to be aware of this.  That
> is the motivation to create this new gdbarch hook.  If the hook is not
> installed, the default version still complies to existing GDB's behavior,
> nothing is changed.

I am of two minds about this. If this is a GCC error, then we should
also think of the error being fixed in GCC - at least at some point.
So, anything we end up doing here should be regarded as a workaround,
and I wouldn't want the workaround to start causing problems the day
the problem is fixed in GCC.

We have the same sort of issue in Ada, where functions returning
types whose size is non-static are transformed into procedures
where the first parameter is the return value. I haven't had the time
to look into this - in particular whether this feature is target-
dependent or not. I think we can get away with it by simply inspecting
the funtion's parameter name (which is not great).

It'd be good if you could show us the debugging information generated
for functions that return values vial the first parameter. Ideally,
there should be some information about this in the functions debug
info. I think that this would be the best way forward - that way,
GDB wouldn't have to juggle a number of factors in order to guess
which convention to use.

In terms of implementation, I think it would be better if we passed
the function's symbol as a parameter to the new gdbarch method, rather
than the return time.  With the symbol, we can determine the language,
which might be a useful thing to have when determining how the result
is returned.

Just a nit, I would name the new method "return_in_hidden_first_param_p"
(although, I think we have more general issues to discuss before we
can really talk about the code).


-- 
Joel