From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30682 invoked by alias); 15 Oct 2012 13:17:06 -0000 Received: (qmail 30673 invoked by uid 22791); 15 Oct 2012 13:17:05 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,MSGID_MULTIPLE_AT,TW_VZ,TW_ZW X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.152) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Oct 2012 13:17:00 +0000 Received: from md16.u-strasbg.fr (md16.u-strasbg.fr [130.79.200.206]) by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id q9FDGvxf042442 for ; Mon, 15 Oct 2012 15:16:57 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from mailserver.u-strasbg.fr (ms13.u-strasbg.fr [130.79.204.113]) by md16.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id q9FDGviI027486 for ; Mon, 15 Oct 2012 15:16:57 +0200 (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from E6510Muller (gw-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id q9FDGvlQ027476 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 15 Oct 2012 15:16:57 +0200 (envelope-from pierre.muller@ics-cnrs.unistra.fr) From: "Pierre Muller" To: References: <83a9vs89r9.fsf@gnu.org> <201210120953.q9C9rqfu020865@glazunov.sibelius.xs4all.nl> <834nm07z0s.fsf@gnu.org> <5077FEB9.4030304@redhat.com> <83y5jb7rfe.fsf@gnu.org> In-Reply-To: Subject: RE: Calling __stdcall functions in the inferior Date: Mon, 15 Oct 2012 13:17:00 -0000 Message-ID: <005d01cdaad7$59f1ecd0$0dd5c670$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-10/txt/msg00071.txt.bz2 Sorry, the email below was supposed to=20 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=20 of this problem. It is related to an assumption=20 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=A0: Pierre Muller [mailto:pierre.muller@ics-cnrs.unistra.fr] > Envoy=E9=A0: vendredi 12 octobre 2012 16:46 > =C0=A0: 'Eli Zaretskii' > Objet=A0: RE: Calling __stdcall functions in the inferior >=20 > Hi Eli, >=20 > I do get the same problem. > (but not with the @0 suffix!) > 1> call 'GetLastError@0'() > $9 =3D 126 > 1> call 'GetLastError'() > gdb: unknown target exception 0xc0000008 at 0x773612f7 >=20 > 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. >=20 >=20 > Did you try to disassemble the code at GetLastError? >=20 > 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. >=20 > 1> x /10i &GetLastError > 0x75758967 : jne 0x75758968 > > 0x75758969 : jae 0x75758987 > > 0x7575896b : pushl 0x18(%ebx) > 0x7575896e : call *0x756c0044 > 0x75758974 : test %al,%al > 0x75758976 : je 0x75758b4a > > 0x7575897c : mov -0x240(%ebp),%eax > 0x75758982 : mov %eax,-0x370(%ebp) > 0x75758988 : movzwl - > 0x244(%ebp),%eax > 0x7575898f : xor %ecx,%ecx >=20 > Exploring the 'GetLastError@0', > I find: >=20 > 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 : jmp 0x756c11c7 > > 0x756c11c2 : nop > 0x756c11c3 : nop > 0x756c11c4 : nop > 0x756c11c5 : nop > 0x756c11c6 : nop > 0x756c11c7 : jmp *0x756c0d9c > 0x756c11cd : nop > 0x756c11ce : nop > 0x756c11cf : nop > 1> x /10i 0x756c11c7 > 0x756c11c7 : jmp *0x756c0d9c > 0x756c11cd : nop > 0x756c11ce : nop > 0x756c11cf : nop > 0x756c11d0 : nop > 0x756c11d1 : nop > 0x756c11d2 : nop > 0x756c11d3 : nop > 0x756c11d4 : nop > 0x756c11d5 : nop > 1> x /x 0x756c0d9c > 0x756c0d9c : 0x74e6786a > 1> x /10i 0x74e6786a > 0x74e6786a : mov %fs:0x18,%eax > 0x74e67870 : mov 0x34(%eax),%eax > 0x74e67873 : ret > This looks like the real code for GetLastError function, > but it is certainly not the same as: 0x75758967 >=20 > I am wondering if this is a problem of DLL information reading... >=20 > Pierre Muller >=20 >=20 > > -----Message d'origine----- > > De=A0: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la part > > de Eli Zaretskii > > Envoy=E9=A0: vendredi 12 octobre 2012 15:26 > > =C0=A0: Pedro Alves > > Cc=A0: mark.kettenis@xs4all.nl; gdb@sourceware.org > > Objet=A0: Re: Calling __stdcall functions in the inferior > > > > > Date: Fri, 12 Oct 2012 12:27:53 +0100 > > > From: Pedro Alves > > > CC: Mark Kettenis , 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.