From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1733 invoked by alias); 6 Apr 2010 14:07:34 -0000 Received: (qmail 1554 invoked by uid 22791); 6 Apr 2010 14:07:31 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=BAYES_00,MSGID_MULTIPLE_AT,TW_DB,TW_DJ,TW_EB,TW_GP,TW_JG,TW_SD X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.155) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 06 Apr 2010 14:07:25 +0000 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id o36E7LA7037627 for ; Tue, 6 Apr 2010 16:07:21 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from mailserver.u-strasbg.fr (ms3.u-strasbg.fr [IPv6:2001:660:2402:d::12]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id o36E7KlG038742 for ; Tue, 6 Apr 2010 16:07:21 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from d620muller (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 o36E7KZo085168 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 6 Apr 2010 16:07:20 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) From: "Pierre Muller" To: References: <002a01cad517$d36eab90$7a4c02b0$@muller@ics-cnrs.unistra.fr> In-Reply-To: <002a01cad517$d36eab90$7a4c02b0$@muller@ics-cnrs.unistra.fr> Subject: RE: Go32-v2 native woes Date: Tue, 06 Apr 2010 14:07:00 -0000 Message-ID: <001501cad592$7ef11230$7cd33690$@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: 2010-04/txt/msg00022.txt.bz2 After some investigation, I find a fix for this, I will send it to gdb-patches list. Pierre Muller Pascal language support maintainer for GDB > -----Message d'origine----- > De=A0: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la > part de Pierre Muller > Envoy=E9=A0: Tuesday, April 06, 2010 1:29 AM > =C0=A0: gdb@sourceware.org > Objet=A0: Go32-v2 native woes >=20 > There are again internal-error problems > with go32v2 native about registers that are > not correct. >=20 > Current CVS gives this: >=20 > Breakpoint 2 at 0xc485: file ../../src/gdb/cli/cli-cmds.c, line 223. > (top-gdb) set prompt top> > #Note top> is an older gdb that works fine. > top> r ./gdb > Starting program: e:/cygwin/usr/local/src/gdbcvs/djcvsbuild/gdb/gdb.exe > ./gdb > GNU gdb (GDB) 7.1.50.20100405-cvs > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "--host=3Di586-pc-msdosdjgpp --target=3Ddjgpp". > For bug reporting instructions, please see: > ... >=20 > Breakpoint 1, internal_error ( > file=3D0xe6d70 "../../src/gdb/target-descriptions.c", line=3D1140, > string=3D0xe6d55 "%s: Assertion `%s' failed.") at > ../../src/gdb/utils.c:1050 > 1050 va_start (ap, string); > top> bt > #0 internal_error (file=3D0xe6d70 "../../src/gdb/target-descriptions.c", > line=3D1140, string=3D0xe6d55 "%s: Assertion `%s' failed.") > at ../../src/gdb/utils.c:1050 > #1 0x000e8cf2 in tdesc_use_registers (gdbarch=3D0x46eda0, > target_desc=3D0x3ed480, > early_data=3D0x46fd90) at ../../src/gdb/target-descriptions.c:1140 > #2 0x0013a17c in i386_gdbarch_init (info=3D..., arches=3D0x0) > at ../../src/gdb/i386-tdep.c:6699 > #3 0x0004dbd6 in gdbarch_find_by_info (info=3D...) > at ../../src/gdb/gdbarch.c:3979 > #4 0x00088785 in set_gdbarch_from_file (abfd=3D0x42c0a0) > at ../../src/gdb/arch-utils.c:552 > #5 0x00017c8b in exec_file_attach (filename=3D0x3eaeb8 "./gdb", > from_tty=3D1) > at ../../src/gdb/exec.c:296 > #6 0x000256dd in catch_command_errors (command=3D0x179e7 > , > arg=3D0x3eaeb8 "./gdb", from_tty=3D1, mask=3D6) at > ../../src/gdb/exceptions.c:525 > #7 0x00002a2a in captured_main (data=3D0x3ea208) at > ../../src/gdb/main.c:808 > #8 0x00025649 in catch_errors (func=3D0x1dfa , > func_args=3D0x3ea208, errstring=3D0x1b94 "", mask=3D6) > at ../../src/gdb/exceptions.c:510 > #9 0x00002d72 in gdb_main (args=3D0x3ea208) at ../../src/gdb/main.c:916 > #10 0x0000180d in main (argc=3D2, argv=3D0x3eaed8) at > ../../src/gdb/gdb.c:33 > top> f 1 > #1 0x000e8cf2 in tdesc_use_registers (gdbarch=3D0x46eda0, > target_desc=3D0x3ed480, > early_data=3D0x46fd90) at ../../src/gdb/target-descriptions.c:1140 > 1140 gdb_assert (VEC_length (tdesc_arch_reg, data->arch_regs) <=3D > num_regs); >=20 > top> p num_regs > $1 =3D 32 > top> p *data.arch_regs > $2 =3D {num =3D 33, alloc =3D 36, vec =3D {{reg =3D 0x3ed6d8, type =3D 0x= 0}}} > top> >=20 > The additional reg in arch_regs seems to come from > i386_validate_tdesc_p function: > /* Need to include %mxcsr, so add one. */ > num_regs +=3D tdep->num_xmm_regs + 1; >=20 > Adding this condition > if (tdep->num_xmm_regs) > removes the problem above, > but I get another error later: > Breakpoint 1 at 0x479d: file ../../src/gdb/utils.c, line 1050. > Breakpoint 2 at 0xc485: file ../../src/gdb/cli/cli-cmds.c, line 223. > (top-gdb) start > Temporary breakpoint 3 at 0x17d4: file ../../src/gdb/gdb.c, line 28. > Starting program: e:/cygwin/usr/local/src/gdbcvs/djcvsbuild/gdb/gdb.exe >=20 > Temporary breakpoint 3, main (argc=3D1, argv=3D0x3eae78) at > ../../src/gdb/gdb.c:28 > 28 memset (&args, 0, sizeof args); > (top-gdb) inf reg > eax 0x10 16 > ecx 0x0 0 > edx 0x100 256 > ebx 0x3f6 1014 > esp 0x3ea1f0 0x3ea1f0 > ebp 0x3ea220 0x3ea220 > esi 0x54 84 > edi 0x36a258 3580504 > eip 0x17d4 0x17d4 > eflags 0x3206 [ PF IF #12 #13 ] > cs 0x28f 655 > ss 0x297 663 > ds 0x297 663 > es 0x297 663 > fs 0x2a7 679 > gs 0x2a7 679 >=20 > Breakpoint 1, internal_error (file=3D0x1286ab "../../src/gdb/go32-nat.c", > line=3D546, string=3D0x128680 "Invalid register no. %d in > fetch_register.") > at ../../src/gdb/utils.c:1050 > 1050 va_start (ap, string); >=20 > GDB is trying to display register 32 which is normally "xmm0" > and thus should not be displayed for go32v2. >=20 > I was not able o fix that second problem :( >=20 > Pierre Muller > Pascal language support maintainer for GDB > and old-DOS lover ...