This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 05/05/2012 01:58 AM, Joel Brobecker wrote:
> I'd like to know what the code is, and what the associated debug info
> looks like today. How many parameters would the debug info list for
> your function above when the return value is passed as a hidden
> parameter?  I am guessing 4. I am pretty sure that this is what GNAT
> does for Ada (IIRC, GNAT emits a parameter named "TARGET" for it).
> 

It is 3, unfortunately.  I got the similar debug info output on both x86
and tic6x:

 <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
 <3><2356>: Abbrev Number: 16 (DW_TAG_formal_parameter)
    <2357>   DW_AT_type        : <0x3b>
 <3><235b>: Abbrev Number: 16 (DW_TAG_formal_parameter)
    <235c>   DW_AT_type        : <0x3b>

> What debug info could do for us is tag that special parameter
> using an attribute like DW_AT_return_address_as_implicit_param.
> Then we could do have a generic mechanism in GDB that picks it
> up, and calls the function appropriately without having to have
> insider knowledge as to when such parameter is being used.
> 

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

> I think there is one avenue that needs to be looked at with
> respect to debugging info: Maybe consult with the DWARF committee
> to see how this type of situation is supposed to be handled.
> Perhaps it's already covered?

Yes, it is a good idea to ask in dwarf-discuss@ to see if people there
have some smart ideas.  Will do.

> 
> Now, I realize that getting the GCC guys to improve the debug
> info might not be easily doable. Perhaps a possible option
> is to identify the special hidden field using some heuristics
> (field name, for instance), and then pretend that this parameter
> had the special DWARF attribute. That way, the day GCC starts
> describing the implict parameters better, it'll just work out
> of the box, and we phase out the hack a few years later.
> 

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 should add that I am badly overloaded these days and I don't
> see it getting better any time soon. It's possible that I am not
> getting what the real problem is simply because I don't know C++
> (I learnt the basics over 15 years ago and haven't used it since).
> Anyone knowing C++ better should feel free to take the discussion
> over.

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++ :)

-- 
Yao (éå)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]