RE: [PATCH v11 01/10] gdb, dwarf: add support for DW_AT_trampoline in DWARF reader

["Ijaz, Abdul B" <abdul.b.ijaz@intel.com>]

Thanks Tom, for the feedback.

Please see the inline reply below:

Tom> One thing I don't understand is why this data is attached to the type, and not to the function's symbol (or perhaps the block structure).

Abdul> The type was chosen because that is where GDB already keeps the other DW_TAG_subprogram attributes that describe how a function behaves: DW_AT_noreturn (TYPE_NO_RETURN) is read in read_subroutine_type and stored in the function type's func_type.  read_subroutine_type is also called for every DW_TAG_subprogram and DW_TAG_inlined_subroutine DIE (read_func_scope creates the symbol with read_type_die), and dwarf2_attr follows DW_AT_abstract_origin, so reading the attribute there covers concrete and inlined instances in one place.  And it kept struct symbol, which is space critical, unchanged, since func_type only exists for functions.

That said, I agree that it is a property of the function and not of its type: DW_AT_trampoline is only allowed on subprograms and inlined subroutines, never on subroutine types (https://dwarfstd.org/doc/DWARF5.pdf [3.3.9 Trampolines]), and all the use cases in the following patches start from the function symbol anyway.   So, for v12 I can  move it to the symbol, as a new symbol subclass like template_symbol  add SYMBOL_TRAMPOLINE to symbol_subclass_kind.   The read_func_scope would allocate it when the DIE has a valid DW_AT_trampoline, as it does for template functions.  Does that sound right to you, or would you prefer the block?

>> +      TYPE_TRAMPOLINE_TARGET (ftype)
>> +	= (trampoline_target *) TYPE_ZALLOC (ftype,
>> +					     sizeof (trampoline_target));

Tom> This zero-initializes so...

>> +	  if (dwarf2_get_pc_bounds (target_die, &lowpc, NULL, target_cu,
>> +				    nullptr, nullptr) <= PC_BOUNDS_INVALID)
>> +	    complaint (_("DW_AT_trampoline target DIE has invalid "
>> +			 "low pc, for referencing DIE %s[in module %s]"),
>> +			 sect_offset_str (die->sect_off),
>> +			 objfile_name (objfile));

Tom>... if the complaint triggers, this will end up with a kind of TRAMPOLINE_TARGET_ADDR and an unrelocated address of 0.
Tom> Perhaps in such a case it's better to avoid marking the function as a trampoline.  That way, if there is a problem in the DWARF, gdb will fall back to the function simply being ordinary.

Abdul> Agreed, I'll only mark the function once the target is known to be valid to allow GDB to fall back to the ordinary function handling.

> > +      else
> > +   TYPE_TRAMPOLINE_TARGET (ftype)->set_target_addr (attr->as_address
> > +());

Tom> This else clause also seems perhaps weird.

Abdul> DWARF only allows the address, flag, reference, and string classes for DW_AT_trampoline.   In v12, I'll handle the forms explicitly (flag forms, address forms, string forms, reference forms) and complain about anything else without marking the function as a trampoline.

Tom> I had some other nits for this patch, but I figured I'd rather find out about the type issue before writing them up.

Abdul> Thanks, I'll wait for those before sending v12.

Best Regards
Abdul Basit

-----Original Message-----
From: Tom Tromey <tom@tromey.com> 
Sent: Wednesday, October 21, 2026 10:34 PM
To: Ijaz, Abdul B <abdul.b.ijaz@intel.com>
Cc: gdb-patches@sourceware.org; JiniSusan.George@amd.com; tom@tromey.com; eliz@gnu.org; Nils-Christian Kempke <nils-christian.kempke@intel.com>
Subject: Re: [PATCH v11 01/10] gdb, dwarf: add support for DW_AT_trampoline in DWARF reader

>>>>> Abdul Basit Ijaz <abdul.b.ijaz@intel.com> writes:

> DW_AT_trampoline can be used to describe compiler generated functions 
> that serve some intermediary purpose on making a call to another 
> function.  A compiler can emit this tag in order to help a debugger 
> hide the trampolines from a user.

> This patch adds support to GDB for reading the DW_AT_trampoline 
> attribute.  It stores the attribute and its value in the type_specific 
> part of a GDB type.  This patch is implemented in preparation of the 
> following patches, which will add a mechanism to hide DW_AT_trampoline 
> subroutines from the user.

One thing I don't understand is why this data is attached to the type, and not to the function's symbol (or perhaps the block structure).

> +      TYPE_TRAMPOLINE_TARGET (ftype)
> +	= (trampoline_target *) TYPE_ZALLOC (ftype,
> +					     sizeof (trampoline_target));

This zero-initializes so...

> +	  if (dwarf2_get_pc_bounds (target_die, &lowpc, NULL, target_cu,
> +				    nullptr, nullptr) <= PC_BOUNDS_INVALID)
> +	    complaint (_("DW_AT_trampoline target DIE has invalid "
> +			 "low pc, for referencing DIE %s[in module %s]"),
> +			 sect_offset_str (die->sect_off),
> +			 objfile_name (objfile));
> +	  else
> +	    TYPE_TRAMPOLINE_TARGET (ftype)->set_target_addr (lowpc);

... if the complaint triggers, this will end up with a kind of TRAMPOLINE_TARGET_ADDR and an unrelocated address of 0.

Perhaps in such a case it's better to avoid marking the function as a trampoline.  That way, if there is a problem in the DWARF, gdb will fall back to the function simply being ordinary.

> +      else if (attr->form_is_unsigned ())
> +	TYPE_TRAMPOLINE_TARGET (ftype)->set_target_flag (attr->as_boolean ());
> +      else
> +	TYPE_TRAMPOLINE_TARGET (ftype)->set_target_addr (attr->as_address 
> +());

This else clause also seems perhaps weird.

I had some other nits for this patch but I figured I'd rather find out about the type issue before writing them up.

Tom
________________________________________
Intel Deutschland GmbH 

Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany 

Tel: +49 (89) 99143-0 

www.intel.de 

Managing Directors: Candice Moore, Jeffrey Schneiderman, Ramachandran Sitaraman

Chairperson of the Supervisory Board: Sonja Pierer

Registered Seat: Munich Commercial Register B: Amtsgericht Munich HRB 186928

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.