Skipping over trampolines/stubs

Skipping over trampolines/stubs

[Jonas Maebe]

Hi,

We have a language construct whereby some calls have to be rerouted  
via a small stubs/trampolines. When encountering such a stub, gdb  
currently does not step into them, because the have no line info  
available (and hence gdb also does not step into the target call  
unless you manually place a breakpoint at the destination).

When the stub is generated in the same source file as where its  
destination lies, I can easily generate the same source info for the  
stub as for the target code, and then everything works fine (at least  
with DWARF; stabs would also require a fake procedure body, at least  
on Mac OS X).

The problem is if the target code is located in a different source  
file. I think I can hack our compiler so it can figure out whether  
that other source file was compiled with debug information and if so,  
what the file/line information of the source file of the target code  
would be, but
it wouldn't be easy and kind of messy.

So I'm wondering whether there's maybe some trick that you can use to  
make gdb step through arbitrary stubs somehow (maybe some kind of fake  
line information that it always ignores and just skips over), or  
whether there is another possible approach.

Thanks,


Jonas

PS, the actual implementation details: it's in case of interfaces in  
Free Pascal (similar to Java interfaces). When you call an interface  
method using a class instance, the self pointer needs to be adjusted  
before the interface method is entered (it has to be changed so it  
points to the interface's vmt). This is done using a small stub, to  
avoid having to inline this code everywhere (it's kind of bulky in  
some cases).

These stubs have to be generated in the source files containing the  
implementations of classes that implements an interface and not in the  
source file of the interface itself, because the adjustment of the  
self pointer depends on the class (depending on how many interfaces it  
implements, and in which order).

Here are a couple of examples of such stubs (the first for a function  
using the stdcall calling convention, the second for one using the  
Borland-style fastcall calling convention):

.globl  _WRPR_P$PROGRAM_TMYCLASS_$_IINTERFACE_$_0_ 
$__SYSTEM_TINTERFACEDOBJECT_$__QUERYINTERFACE$TGUID$formal$$LONGINT
_WRPR_P$PROGRAM_TMYCLASS_$_IINTERFACE_$_0_$__SYSTEM_TINTERFACEDOBJECT_ 
$__QUERYINTERFACE$TGUID$formal$$LONGINT:
         subl    $12,4(%esp)
         jmp     L_SYSTEM_TINTERFACEDOBJECT_$__QUERYINTERFACE$TGUID 
$formal$$LONGINT$stub

.globl  _WRPR_P$PROGRAM_TMYCLASS_$_IINTERFACE_$_3_$__P 
$PROGRAM_TMYCLASS_$__MYDO
_WRPR_P$PROGRAM_TMYCLASS_$_IINTERFACE_$_3_$__P$PROGRAM_TMYCLASS_$__MYDO:
         subl    $12,%eax
         pushl   %ebx
         pushl   %eax
         movl    (%eax),%eax
         movl    80(%eax),%eax
         movl    %eax,4(%esp)
         popl    %eax
         ret

Re: Skipping over trampolines/stubs

[Daniel Jacobowitz]

On Wed, Apr 01, 2009 at 09:08:11PM +0200, Jonas Maebe wrote:
> So I'm wondering whether there's maybe some trick that you can use to  
> make gdb step through arbitrary stubs somehow (maybe some kind of fake  
> line information that it always ignores and just skips over), or whether 
> there is another possible approach.

GDB already supports this for other languages; I suggest just adding
detection of the Free Pascal stubs to the debugger.  ObjC and C++
both have similar requirements, I believe.  In C++ they're virtual
call thunks.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Skipping over trampolines/stubs

[Jonas Maebe]

On 01 Apr 2009, at 21:14, Daniel Jacobowitz wrote:

> On Wed, Apr 01, 2009 at 09:08:11PM +0200, Jonas Maebe wrote:
>>>
> GDB already supports this for other languages; I suggest just adding
> detection of the Free Pascal stubs to the debugger.  ObjC and C++
> both have similar requirements, I believe.  In C++ they're virtual
> call thunks.

Thanks. Given that tracing some of these stubs requires access to the  
parameters, I should start with adding support for the Borland  
fastcall calling convention to gdb. The reason is that this is our  
default calling convention on i386 platforms, mainly for Delphi  
compatibility reasons (quite a bit of unparametrised assembler code  
there).

Which brings me to the next point: how does one go about "allocating"  
a new DW_AT_calling_convention value in the DW_CC_lo_user ..  
DW_CC_hi_user range? At first sight, there is only one such value  
currently in public use (DW_CC_GNU_renesas_sh). Can I just take 0x41  
for DW_CC_BORLAND_fastcall_i386? And should I then submit this  
constant for inclusion in binutils first?


Jonas

Re: Skipping over trampolines/stubs

[Daniel Jacobowitz]

On Wed, Apr 01, 2009 at 10:15:33PM +0200, Jonas Maebe wrote:
> Thanks. Given that tracing some of these stubs requires access to the  
> parameters, I should start with adding support for the Borland fastcall 
> calling convention to gdb. The reason is that this is our default calling 
> convention on i386 platforms, mainly for Delphi compatibility reasons 
> (quite a bit of unparametrised assembler code there).
>
> Which brings me to the next point: how does one go about "allocating" a 
> new DW_AT_calling_convention value in the DW_CC_lo_user .. DW_CC_hi_user 
> range? At first sight, there is only one such value currently in public 
> use (DW_CC_GNU_renesas_sh). Can I just take 0x41 for 
> DW_CC_BORLAND_fastcall_i386? And should I then submit this constant for 
> inclusion in binutils first?

I don't know - might want to raise this on the DWARF discussion list
(see dwarfstd.org).

-- 
Daniel Jacobowitz
CodeSourcery

Re: Skipping over trampolines/stubs

[Jonas Maebe]

On 01 Apr 2009, at 22:19, Daniel Jacobowitz wrote:

> On Wed, Apr 01, 2009 at 10:15:33PM +0200, Jonas Maebe wrote:
>> Which brings me to the next point: how does one go about  
>> "allocating" a
>> new DW_AT_calling_convention value in the DW_CC_lo_user ..  
>> DW_CC_hi_user
>> range? At first sight, there is only one such value currently in  
>> public
>> use (DW_CC_GNU_renesas_sh). Can I just take 0x41 for
>> DW_CC_BORLAND_fastcall_i386? And should I then submit this constant  
>> for
>> inclusion in binutils first?
>
> I don't know - might want to raise this on the DWARF discussion list
> (see dwarfstd.org).

In case anyone else would ever wonder about this, below is the first  
answer I received (since the archives for the dwarf-discuss list are  
limited to subscribers). It appears that it's entirely up to binutils/ 
gdb maintainers in this case.


Jonas

	From: 	roland at redhat.com
	Subject: Re: [Dwarf-Discuss] Reserving a new DW_AT_calling_convention  
value
	Date: 	Wed 1 Apr 2009 23:26:58 GMT+02:00
	To: 	jonas.maebe@elis.ugent.be
	Cc: 	dwarf-discuss@lists.dwarfstd.org

> I would like to use a new DW_AT_calling_convention attribute value in
> the range DW_CC_lo_user .. DW_CC_hi_user. As far as I can tell, the
> only one currently in (public) use is DW_CC_GNU_renesas_sh (= 0x40).
> My question is: how does one go about reserving/obtaining such a
> number? Do you just take the next one that appears to be available and
> submit patches using this value to binutils (for elf/dwarf.h) and gdb?
> (and possibly dwarflib, and maybe others)

In the lo_user..hi_user range, it is up to each "vendor" to decide the
conventions for using that range.  The different implementors  
("vendors")
try to stay aware of each other's uses, but "vendor-specific extensions"
means exactly that there is not any shared formal management of that  
space.

The DWARF committee decides on the common uses in the <lo_user range.
It's entirely reasonable to propose new values in the common range.

For ELF and DWARF "vendor" stuff in the GNU and Linux world, the  
convention
is consensus of the binutils, elfutils, and (when relevant) GCC  
maintainers.
If you propose your patches for binutils/gdb and gcc in the normal  
ways on
those mailing lists, that will do it.


Thanks,
Roland