* Skipping over trampolines/stubs
@ 2009-04-01 19:08 Jonas Maebe
2009-04-01 19:14 ` Daniel Jacobowitz
0 siblings, 1 reply; 5+ messages in thread
From: Jonas Maebe @ 2009-04-01 19:08 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Skipping over trampolines/stubs
2009-04-01 19:08 Skipping over trampolines/stubs Jonas Maebe
@ 2009-04-01 19:14 ` Daniel Jacobowitz
2009-04-01 20:15 ` Jonas Maebe
0 siblings, 1 reply; 5+ messages in thread
From: Daniel Jacobowitz @ 2009-04-01 19:14 UTC (permalink / raw)
To: Jonas Maebe; +Cc: gdb
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Skipping over trampolines/stubs
2009-04-01 19:14 ` Daniel Jacobowitz
@ 2009-04-01 20:15 ` Jonas Maebe
2009-04-01 20:20 ` Daniel Jacobowitz
0 siblings, 1 reply; 5+ messages in thread
From: Jonas Maebe @ 2009-04-01 20:15 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Skipping over trampolines/stubs
2009-04-01 20:15 ` Jonas Maebe
@ 2009-04-01 20:20 ` Daniel Jacobowitz
2009-04-01 21:40 ` Jonas Maebe
0 siblings, 1 reply; 5+ messages in thread
From: Daniel Jacobowitz @ 2009-04-01 20:20 UTC (permalink / raw)
To: Jonas Maebe; +Cc: gdb
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Skipping over trampolines/stubs
2009-04-01 20:20 ` Daniel Jacobowitz
@ 2009-04-01 21:40 ` Jonas Maebe
0 siblings, 0 replies; 5+ messages in thread
From: Jonas Maebe @ 2009-04-01 21:40 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-04-01 21:40 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-04-01 19:08 Skipping over trampolines/stubs Jonas Maebe
2009-04-01 19:14 ` Daniel Jacobowitz
2009-04-01 20:15 ` Jonas Maebe
2009-04-01 20:20 ` Daniel Jacobowitz
2009-04-01 21:40 ` Jonas Maebe
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox