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

[Joel Brobecker <brobecker@adacore.com>]

Hi Yao,

>  <2><233a>: Abbrev Number: 45 (DW_TAG_subprogram)
>     <233b>   DW_AT_external    : 1
>     <233c>   DW_AT_name        : (indirect string, offset: 0x1759):
> substr
>     <2340>   DW_AT_decl_file   : 9
>     <2341>   DW_AT_decl_line   : 2004
>     <2343>   DW_AT_MIPS_linkage_name: (indirect string, offset: 0x297d):
> _ZNKSs6substrEjj
>     <2347>   DW_AT_type        : <0x1160>
>     <234b>   DW_AT_declaration : 1
>     <234c>   DW_AT_sibling     : <0x2361>
>  <3><2350>: Abbrev Number: 15 (DW_TAG_formal_parameter)
>     <2351>   DW_AT_type        : <0x2466>
>     <2355>   DW_AT_artificial  : 1


What's the relationship between the first parameter's type (DIE 0x2466)
and the function's published returned type (DIE 0x2466)? Is one a
reference type of the other, for instance?

Basically, what I'm trying to help us find is a heuristic that would
be based purely on the DWARF info, rather than on implementation
knowledge from the compiler.  That way, we can try supporting the
current compiler, while at least trying to define what the standard
method should be (meaning that you don't need to be the one who
coordinates the effort of cleaning that up).

> Yes, we need some new tag to describe for this situation.

I saw the discussion you started on dwarf-discuss. Thanks!

> The heuristics in my mind is to do prologue analysis, to see how many
> parameters are expected in sub routine, but not sure how reliable and
> effective it is.

I don't think that's a good idea. Too specialized, and too fragile.
And thanks to DWARF frame information, it's something we're slowly
getting away from.

> This problem is caused by C++ argument passing in inf-call, but not a
> C++ problem, IMO.  Any one here should be able to comment on this
> patch, don't be scared by C++ :)

I have a better picture of the problem thanks you the copy of
the debug info. I agree it's not a C++-specific problem. I was just
invinting others to comment as well. I don't want to be too lax
and allow a detection method which I think isn't going to scale well.
But at the same time, I don't want to be too strict, and discourage
you. Having others comment on the issue might bring some ideas we
haven't had yet, or correct me on my understanding.

-- 
Joel