This is the mail archive of the gdb@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]

Skipping over trampolines/stubs


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



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