Calling __stdcall functions in the inferior

Calling __stdcall functions in the inferior

[Eli Zaretskii]

Is there a way to call __stdcall functions in the inferior from GDB,
while debugging a C program?  The case in point is GetLastError, but
any other function from the Windows API has this problem.

TIA

Re: Calling __stdcall functions in the inferior

[Mark Kettenis]

> Date: Fri, 12 Oct 2012 08:50:02 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> Is there a way to call __stdcall functions in the inferior from GDB,
> while debugging a C program?  The case in point is GetLastError, but
> any other function from the Windows API has this problem.

Probably not.  We only implement the System V and Darwin calling
conventions for i386.

I'm not familliar with the Windows world (and don't really have a
desire to become familliar).  But I assume "normal" (non-__stdcall)
functions use the System V calling conventions?  In that case there
are two things that will need to happen:

* You'll need to implement Windows-specific push_dummy_call and/or
  push_dummy_code gdbarch methods for calling __stdcall functions.

* You'll need to figure out a way to distinguish __stdcall functions
  from "normal" functions.

If you decide to have a go at this, please create a new
i386-windows-tdep.c file to put all the Windows-specific i386 code.

Re: Calling __stdcall functions in the inferior

[John Gilmore]

> > Is there a way to call __stdcall functions in the inferior from GDB,
> > while debugging a C program?  The case in point is GetLastError, but
> > any other function from the Windows API has this problem.

If you just need this capability to debug a particular problem, add a
dummy debugging function to the source code of your buggy program,
which has the normal calling sequence, and which just calls
GetLastError and returns its result.  Then call *that* function from
GDB.

	John

Re: Calling __stdcall functions in the inferior

[Eli Zaretskii]

> cc: eliz@gnu.org, gdb@sourceware.org
> Date: Fri, 12 Oct 2012 03:20:22 -0700
> From: John Gilmore <gnu@toad.com>
> 
> If you just need this capability to debug a particular problem, add a
> dummy debugging function to the source code of your buggy program,
> which has the normal calling sequence, and which just calls
> GetLastError and returns its result.  Then call *that* function from
> GDB.

Yes, Emacs on Windows already does that.  I just thought there's a
better way, but I guess not.

Thanks.

Re: Calling __stdcall functions in the inferior

[Eli Zaretskii]

> Date: Fri, 12 Oct 2012 11:53:52 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: gdb@sourceware.org
> 
> > Date: Fri, 12 Oct 2012 08:50:02 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > Is there a way to call __stdcall functions in the inferior from GDB,
> > while debugging a C program?  The case in point is GetLastError, but
> > any other function from the Windows API has this problem.
> 
> Probably not.  We only implement the System V and Darwin calling
> conventions for i386.

But we also support Pascal, AFAIK, which uses this convention: the
callee pops the stack.  The only difference is that the arguments are
pushed right to left, unlike with Pascal.  So I thought we already had
this somewhere...

> I'm not familliar with the Windows world (and don't really have a
> desire to become familliar).  But I assume "normal" (non-__stdcall)
> functions use the System V calling conventions?

Yes, it's the normal cdecl calling convention.

> * You'll need to figure out a way to distinguish __stdcall functions
>   from "normal" functions.

Does someone know where GCC stashes this info?  "ptype" doesn't reveal
this detail, AFAICS.

Thanks.

Re: Calling __stdcall functions in the inferior

[Pedro Alves]

On 10/12/2012 11:41 AM, Eli Zaretskii wrote:

>> * You'll need to figure out a way to distinguish __stdcall functions
>>   from "normal" functions.
> 
> Does someone know where GCC stashes this info?  "ptype" doesn't reveal
> this detail, AFAICS.

Not sure about debug info, but the (linker) symbol has a "@number" suffix
appended.  A.k.a., "decoration".  Like "symbol@4".

In gcc/config/i386/winnt.c:

  /* Return string which is the function name, identified by ID, modified
     with a suffix consisting of an atsign (@) followed by the number of
     bytes of arguments.  If ID is NULL use the DECL_NAME as base. If
     FASTCALL is true, also add the FASTCALL_PREFIX.
     Return NULL if no change required.  */

  static tree
  gen_stdcall_or_fastcall_suffix (tree decl, tree id, bool fastcall)
  {

As you see above, fastcall also has identifiable decoration.

I don't recall the rules or conditions of when the decoration is
stripped or not anymore.

See e.g., http://stackoverflow.com/questions/8063842/mingw32-g-and-stdcall-suffix?rq=1

-- 
Pedro Alves

Re: Calling __stdcall functions in the inferior

[Eli Zaretskii]

> Date: Fri, 12 Oct 2012 12:27:53 +0100
> From: Pedro Alves <palves@redhat.com>
> CC: Mark Kettenis <mark.kettenis@xs4all.nl>, gdb@sourceware.org
> 
> In gcc/config/i386/winnt.c:
> 
>   /* Return string which is the function name, identified by ID, modified
>      with a suffix consisting of an atsign (@) followed by the number of
>      bytes of arguments.  If ID is NULL use the DECL_NAME as base. If
>      FASTCALL is true, also add the FASTCALL_PREFIX.
>      Return NULL if no change required.  */
> 
>   static tree
>   gen_stdcall_or_fastcall_suffix (tree decl, tree id, bool fastcall)
>   {
> 
> As you see above, fastcall also has identifiable decoration.

Thanks.

RE: Calling __stdcall functions in the inferior

[Pierre Muller]

  Sorry, the email below was supposed to 
be for the list, but I forgot to check the recipient and sent
it only to Eli first.

  I think that I found a possible cause 
of this problem. It is related to an assumption 
that is currently made in gdb source about windows DLL
that the '.text' section starts at offset 0x1000 relative
to the image base.
  This assumption is wrong for a number of Windows system DLLs.
I will send a RFC email proposing a fix of this
problem.

Pierre

> -----Message d'origine-----
> De : Pierre Muller [mailto:pierre.muller@ics-cnrs.unistra.fr]
> Envoyé : vendredi 12 octobre 2012 16:46
> À : 'Eli Zaretskii'
> Objet : RE: Calling __stdcall functions in the inferior
> 
> Hi Eli,
> 
>   I do get the same problem.
> (but not with the @0 suffix!)
> 1> call 'GetLastError@0'()
> $9 = 126
> 1> call 'GetLastError'()
> gdb: unknown target exception 0xc0000008 at 0x773612f7
> 
> Program received signal ?, Unknown signal.
> 0x7750f9d2 in ntdll!RtlUpdateClonedSRWLock () from
> C:\Windows\system32\ntdll.dll
> The program being debugged was signaled while in a function called from
GDB.
> GDB remains in the frame where the signal was received.
> To change this behavior use "set unwindonsignal on".
> Evaluation of the expression containing the function
> (KERNEL32!GetLastError) will be abandoned.
> When the function is done executing, GDB will silently stop.
> 
> 
>   Did you try to disassemble the code at GetLastError?
> 
> On my Windows64 bit machine, that code looks quite weird:
> Maybe this is Windows64 bit specific?... No,
> I checked on a 32bit machine, and found the same problem.
> 
> 1> x /10i &GetLastError
>    0x75758967 <KERNEL32!GetLastError>:  jne    0x75758968
> <KERNEL32!GetLastError+1>
>    0x75758969 <KERNEL32!GetLastError+2>:        jae    0x75758987
> <KERNEL32!GetConsoleCursorMode>
>    0x7575896b <KERNEL32!GetLastError+4>:        pushl  0x18(%ebx)
>    0x7575896e <KERNEL32!GetLastError+7>:        call   *0x756c0044
>    0x75758974 <KERNEL32!GetLastError+13>:       test   %al,%al
>    0x75758976 <KERNEL32!GetLastError+15>:       je     0x75758b4a
> <SetConsoleScreenBufferInfoEx+3>
>    0x7575897c <KERNEL32!GetLastError+21>:       mov    -0x240(%ebp),%eax
>    0x75758982 <KERNEL32!GetLastError+27>:       mov    %eax,-0x370(%ebp)
>    0x75758988 <KERNEL32!GetConsoleCursorMode+1>:        movzwl -
> 0x244(%ebp),%eax
>    0x7575898f <KERNEL32!GetConsoleCursorMode+8>:        xor    %ecx,%ecx
> 
> Exploring the 'GetLastError@0',
> I find:
> 
> 1> disas 'GetLastError@0'
> Dump of assembler code for function GetLastError@0:
>    0x00722a9c <+0>:     jmp    *0x9a7528
>    0x00722aa2 <+6>:     nop
>    0x00722aa3 <+7>:     nop
> End of assembler dump.
> 1> x /x 0x9a7528
> 0x9a7528 <_imp__GetLastError@0>:        0x756c11c0
> 1> x /10i  0x756c11c0
>    0x756c11c0 <KERNEL32!GetPrivateProfileStructA+6032>: jmp    0x756c11c7
> <KERNEL32!GetPrivateProfileStructA+6039>
>    0x756c11c2 <KERNEL32!GetPrivateProfileStructA+6034>: nop
>    0x756c11c3 <KERNEL32!GetPrivateProfileStructA+6035>: nop
>    0x756c11c4 <KERNEL32!GetPrivateProfileStructA+6036>: nop
>    0x756c11c5 <KERNEL32!GetPrivateProfileStructA+6037>: nop
>    0x756c11c6 <KERNEL32!GetPrivateProfileStructA+6038>: nop
>    0x756c11c7 <KERNEL32!GetPrivateProfileStructA+6039>: jmp    *0x756c0d9c
>    0x756c11cd <KERNEL32!GetPrivateProfileStructA+6045>: nop
>    0x756c11ce <KERNEL32!GetPrivateProfileStructA+6046>: nop
>    0x756c11cf <KERNEL32!GetPrivateProfileStructA+6047>: nop
> 1> x /10i  0x756c11c7
>    0x756c11c7 <KERNEL32!GetPrivateProfileStructA+6039>: jmp    *0x756c0d9c
>    0x756c11cd <KERNEL32!GetPrivateProfileStructA+6045>: nop
>    0x756c11ce <KERNEL32!GetPrivateProfileStructA+6046>: nop
>    0x756c11cf <KERNEL32!GetPrivateProfileStructA+6047>: nop
>    0x756c11d0 <KERNEL32!GetPrivateProfileStructA+6048>: nop
>    0x756c11d1 <KERNEL32!GetPrivateProfileStructA+6049>: nop
>    0x756c11d2 <KERNEL32!GetPrivateProfileStructA+6050>: nop
>    0x756c11d3 <KERNEL32!GetPrivateProfileStructA+6051>: nop
>    0x756c11d4 <KERNEL32!GetPrivateProfileStructA+6052>: nop
>    0x756c11d5 <KERNEL32!GetPrivateProfileStructA+6053>: nop
> 1> x /x  0x756c0d9c
> 0x756c0d9c <KERNEL32!GetPrivateProfileStructA+4972>:    0x74e6786a
> 1> x /10i  0x74e6786a
>    0x74e6786a <KERNELBASE!GetLocaleInfoA>:      mov    %fs:0x18,%eax
>    0x74e67870 <KERNELBASE!GetLocaleInfoA+6>:    mov    0x34(%eax),%eax
>    0x74e67873 <KERNELBASE!GetLocaleInfoA+9>:    ret
> This looks like the real code for GetLastError function,
> but it is certainly not the same as: 0x75758967
> 
> I am wondering if this is a problem of DLL information reading...
> 
> Pierre Muller
> 
> 
> > -----Message d'origine-----
> > De : gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la
part
> > de Eli Zaretskii
> > Envoyé : vendredi 12 octobre 2012 15:26
> > À : Pedro Alves
> > Cc : mark.kettenis@xs4all.nl; gdb@sourceware.org
> > Objet : Re: Calling __stdcall functions in the inferior
> >
> > > Date: Fri, 12 Oct 2012 12:27:53 +0100
> > > From: Pedro Alves <palves@redhat.com>
> > > CC: Mark Kettenis <mark.kettenis@xs4all.nl>, gdb@sourceware.org
> > >
> > > In gcc/config/i386/winnt.c:
> > >
> > >   /* Return string which is the function name, identified by ID,
> modified
> > >      with a suffix consisting of an atsign (@) followed by the number
of
> > >      bytes of arguments.  If ID is NULL use the DECL_NAME as base. If
> > >      FASTCALL is true, also add the FASTCALL_PREFIX.
> > >      Return NULL if no change required.  */
> > >
> > >   static tree
> > >   gen_stdcall_or_fastcall_suffix (tree decl, tree id, bool fastcall)
> > >   {
> > >
> > > As you see above, fastcall also has identifiable decoration.
> >
> > Thanks.

Re: Calling __stdcall functions in the inferior

[Mark Kettenis]

> Date: Fri, 12 Oct 2012 12:41:55 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Fri, 12 Oct 2012 11:53:52 +0200 (CEST)
> > From: Mark Kettenis <mark.kettenis@xs4all.nl>
> > CC: gdb@sourceware.org
> > 
> > > Date: Fri, 12 Oct 2012 08:50:02 +0200
> > > From: Eli Zaretskii <eliz@gnu.org>
> > > 
> > > Is there a way to call __stdcall functions in the inferior from GDB,
> > > while debugging a C program?  The case in point is GetLastError, but
> > > any other function from the Windows API has this problem.
> > 
> > Probably not.  We only implement the System V and Darwin calling
> > conventions for i386.
> 
> But we also support Pascal, AFAIK, which uses this convention: the
> callee pops the stack.  The only difference is that the arguments are
> pushed right to left, unlike with Pascal.  So I thought we already had
> this somewhere...

The way call dummies work, the fact that the callee pops the stack
shouldn't be an issue.

Re: Calling __stdcall functions in the inferior

[Eli Zaretskii]

> Date: Fri, 12 Oct 2012 13:44:49 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: gdb@sourceware.org
> 
> The way call dummies work, the fact that the callee pops the stack
> shouldn't be an issue.

Then what could be the reason that

  (gdb) p GetLastError ()

crashes?  Here's what get:

  (gdb) p GetLastError()

  Program received signal SIGSEGV, Segmentation fault.
  0x7c809163 in KERNEL32!InitializeSListHead ()
     from C:\WINDOWS\system32\kernel32.dll
  The program being debugged was signaled while in a function called from GDB.
  GDB remains in the frame where the signal was received.
  To change this behavior use "set unwindonsignal on".
  Evaluation of the expression containing the function
  (KERNEL32!GetLastError) will be abandoned.
  When the function is done executing, GDB will silently stop.