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

[Yao Qi <yao at codesourcery dot com>]

On 05/03/2012 09:14 AM, Joel Brobecker wrote:
> 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.
> 
Joel, thanks for the review.

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.

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

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".  However, GDB pass four parameters unconditionally, which
causes trouble.

The debug information (.debug_frame is most relevant in this case I
guess) is about in a certain function, which registers are stored in
which place.  So debug infor can't tell how registers are used to pass
parameters during a function call, which should be covered by "calling
convention", usually part of ABI.

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

The new hook name might be renamed to
'pass_return_loc_in_first_hidden_param_p'.

-- 
Yao (éå)