From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26112 invoked by alias); 2 Apr 2012 11:57:53 -0000 Received: (qmail 25984 invoked by uid 22791); 2 Apr 2012 11:57:52 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (194.98.77.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 02 Apr 2012 11:57:32 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 7F638290083; Mon, 2 Apr 2012 13:57:36 +0200 (CEST) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tLCRd8Ka6Ki; Mon, 2 Apr 2012 13:57:36 +0200 (CEST) Received: from ulanbator.act-europe.fr (ulanbator.act-europe.fr [10.10.1.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id 6B3EA29004F; Mon, 2 Apr 2012 13:57:36 +0200 (CEST) Subject: Re: PR13901 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Tristan Gingold In-Reply-To: Date: Mon, 02 Apr 2012 11:57:00 -0000 Cc: gdb@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <14D51CD4-4990-4B11-952C-64EB8F791306@adacore.com> References: <20120330134210.GA7869@bromo.med.uc.edu> To: Jack Howarth X-IsSubscribed: yes 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-04/txt/msg00003.txt.bz2 On Apr 2, 2012, at 12:44 PM, Tristan Gingold wrote: >=20 > On Mar 30, 2012, at 3:42 PM, Jack Howarth wrote: >=20 >> Tristan, >> Have you noticed that recent FSF gdb releases including 7.4 have been >> non-functional when built targeting i386-apple-darwin? The run-time fail= ures >> have changed between 7.2 and 7.4. Currently the failure is exhibited as >> errors of the form... >>=20 >> (gdb) break main >> Breakpoint 1 at 0xd80: file himenoBMTxpa.c, line 71. >> (gdb) r >> Starting program: /Users/howarth/a.out=20 >> darwin_set_sstep: unknown flavour: 4 >> Error calling thread_get_state for GP registers for thread 0x8451lxwarni= ng: >> Mach error at "i386-darwin-nat.c:118" in function >> "i386_darwin_fetch_inferior_registers": (os/kern) invalid argument (0x4) >>=20 >> http://sourceware.org/bugzilla/show_bug.cgi?id=3D13901 >>=20 >> Is this something that is trivial to fix? It would be nice if both MacPo= rts >> and fink could have a functional i386 build of FSF gdb. In fink, we curr= ently >> have gdb restricted to x86_64 fink (although the x86_64-apple-darwin bui= ld >> can debug i386 binaries fine). MacPorts has left their gdb pacakge at 7.1 >> (which I guess is that last version that worked for both i386-apple-darw= in >> and x86_64-apple-darwin. Thanks in advance for any clarifications. >=20 > I now understand the issue: >=20 > gdb spawns bash to run the program, but the bash spawned is 64 bits, whic= h is not understood by gdb... Fixed by this patch (committed on trunk): 2012-04-02 Tristan Gingold PR gdb/13901 * darwin-nat.c (darwin_execvp): Sey binary preference. Index: darwin-nat.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/src/src/gdb/darwin-nat.c,v retrieving revision 1.31 diff -c -r1.31 darwin-nat.c *** darwin-nat.c 14 Mar 2012 01:46:59 -0000 1.31 --- darwin-nat.c 2 Apr 2012 11:55:36 -0000 *************** *** 39,44 **** --- 39,45 ---- #include "value.h" #include "arch-utils.h" #include "bfd.h" + #include "bfd/mach-o.h" =20=20 #include #include *************** *** 1538,1543 **** --- 1539,1560 ---- return; } =20=20 + /* Specify the same binary preference to spawn the shell as the + exec binary. This avoids spawning a 64bit shell while debugging + a 32bit program, which may confuse gdb. + Also, this slightly breaks internal layers as we suppose the binary + is Mach-O. Doesn't harm in practice. */ + if (exec_bfd !=3D NULL) + { + cpu_type_t pref; + size_t ocount; +=20 + pref =3D bfd_mach_o_get_data (exec_bfd)->header.cputype; + res =3D posix_spawnattr_setbinpref_np (&attr, 1, &pref, &ocount); + if (res !=3D 0 || ocount !=3D 1) + fprintf_unfiltered (gdb_stderr, "Cannot set posix_spawn binpref\n"); + } +=20 posix_spawnp (NULL, argv[0], NULL, &attr, argv, env); } =20=20