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

[Yao Qi <yao@codesourcery.com>]

On 05/08/2012 04:13 AM, Joel Brobecker wrote:
> 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
                                              ^^^^^^^^^^^
I guess you meant DIE 0x1160 here.

> reference type of the other, for instance?

Yes, I think so.

 <2><22b>: Abbrev Number: 10 (DW_TAG_structure_type)
    <22c>   DW_AT_name        : (indirect string, offset: 0x17c): basic_string<char, std::char_traits<char>, std::allocator<char> >
    <230>   DW_AT_declaration : 1
    <231>   DW_AT_sibling     : <0x271>

 <1><1160>: Abbrev Number: 53 (DW_TAG_structure_type)
    ^^^^^^^  <- function's return type

    <1161>   DW_AT_specification: <0x22b>
    <1165>   DW_AT_byte_size   : 4
    <1166>   DW_AT_decl_file   : 7
    <1167>   DW_AT_decl_line   : 52
    <1168>   DW_AT_sibling     : <0x2461>

 <1><2466>: Abbrev Number: 38 (DW_TAG_pointer_type)
    ^^^^^^  <- 1st param's type

    <2467>   DW_AT_byte_size   : 4     
    <2468>   DW_AT_type        : <0x246c>
 <1><246c>: Abbrev Number: 37 (DW_TAG_const_type)
    <246d>   DW_AT_type        : <0x1160>     
                                 ^^^^^^^^

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

Agreed.  I stared at these debug info for a while, but unable to have
a clue on heuristics.  My feeling is that these debug info doesn't give
us more than what source code can give, but the heuristics we are looking
for are about the difference on different targets, given the same source.
That is to say, on different targets, although the number of parameters
is different, the debug info is almost the same and hard to get heuristics,

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

Yeah, indeed! :)

-- 
Yao (齐尧)