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

[Chung-Lin Tang <cltang@codesourcery.com>]

On 12/5/3 9:14 AM, Joel Brobecker wrote:
>> 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.

It's hard to say whether this should be something fixed in GCC at all,
for this just creates yet another C++ ABI version (at least for some
architectures) :P

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

There isn't really anything wrong with how GDB determines this from the
type information (the gnu-v3-abi.c code here for C++). The problem is
that GCC is inaccurate, making this kind of language-dependent decision
impossible in general; it has to be augmented with target-specific
information.

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

Currently, as you can see from the small GCC code excerpt from Yao's
first mail, GCC internally abstracts away the details of 'aggregate
types', so I'm not sure if there are any language specific
considerations here...

If convenient, maybe you can try out how the manual call feature for Ada
works? i.e. call a function where the aforementioned kind of Ada type is
returned, and see how GDB behaves. If SH or C6x is too exotic, hppa and
(probably) 32-bit SPARC should also exhibit similarly failing behavior.

Thanks,
Chung-Lin