This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
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 (éå)