From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8863 invoked by alias); 2 Apr 2012 14:07:09 -0000 Received: (qmail 8854 invoked by uid 22791); 2 Apr 2012 14:07:08 -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 14:06:50 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id ED81B29006A; Mon, 2 Apr 2012 16:06:53 +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 4whf3ToefQse; Mon, 2 Apr 2012 16:06:53 +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 C351C29005E; Mon, 2 Apr 2012 16:06:53 +0200 (CEST) Subject: Re: PR13901 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Tristan Gingold In-Reply-To: <4F79AFF4.9000704@redhat.com> Date: Mon, 02 Apr 2012 14:07:00 -0000 Cc: Jack Howarth , gdb@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <54AC9EED-A577-41CA-B09D-3ED879877D0C@adacore.com> References: <20120330134210.GA7869@bromo.med.uc.edu> <14D51CD4-4990-4B11-952C-64EB8F791306@adacore.com> <4F79AFF4.9000704@redhat.com> To: Pedro Alves 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/msg00007.txt.bz2 On Apr 2, 2012, at 3:56 PM, Pedro Alves wrote: > On 04/02/2012 12:57 PM, Tristan Gingold wrote: >=20 >> On Apr 2, 2012, at 12:44 PM, Tristan Gingold wrote: >>>> On Mar 30, 2012, at 3:42 PM, Jack Howarth wrote: >=20 >>>>>> (gdb) break main >=20 >>>>>> 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 0x8451lxw= arning: >>>>>> Mach error at "i386-darwin-nat.c:118" in function >>>>>> "i386_darwin_fetch_inferior_registers": (os/kern) invalid argument (= 0x4) >=20 >=20 >>>> I now understand the issue: >>>>=20 >>>> gdb spawns bash to run the program, but the bash spawned is 64 bits, w= hich is not understood by gdb... >> Fixed by this patch (committed on trunk): >=20 >=20 > I don't know much about darwin/osx >=20 > This assumes there's even a 32-bit version of the user's whatever $SHELL. > Not sure we can claim that's always true? It also doesn't feel right > to force a different $SHELL version/build of the shell that runs if GDB > is not involved. Very unlikely to cause problems, but still... Indeed, this is very unlikely, but I understand the concern. > Why does GDB need to touch the shell's registers at all in the first plac= e? I haven't checked why. > If we can't skip darwin_set_sstep for all continues that are not single-s= teps, > we could at least skip those while starting up (when continuing the shell > until we see enough execs). That'd suggest a new flag like > darwin-nat.h:struct private_inferior->starting_up, set and cleared in > darwin_create_inferior, and then making darwin_resume_thread do: >=20 > - /* Set single step. */ > - inferior_debug (4, _("darwin_set_sstep (thread=3D%x, enable=3D%d)\n= "), > - thread->gdb_port, step); > - darwin_set_sstep (thread->gdb_port, step); > + /* Avoid touching the $SHELL process, and go straight to resuming i= t. */ > + gdb_assert (!inf->private->starting_up || !step); > + if (!inf->private->starting_up) > + { > + /* Set single step. */ > + inferior_debug (4, _("darwin_set_sstep (thread=3D%x, enable=3D%= d)\n"), > + thread->gdb_port, step); > + darwin_set_sstep (thread->gdb_port, step); >=20 > WDYT? Yes, it might be cleaner. Honestly, I'd prefer to get rid of the shell step and directly execute the = user program - or at least have an option to do that. I think I also under= stand the cons of this approach. Tristan.