From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3406 invoked by alias); 2 Apr 2012 13:56:47 -0000 Received: (qmail 3392 invoked by uid 22791); 2 Apr 2012 13:56:46 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 02 Apr 2012 13:56:29 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q32Du5Gw026111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Apr 2012 09:56:05 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q32Du4sN023927; Mon, 2 Apr 2012 09:56:04 -0400 Message-ID: <4F79AFF4.9000704@redhat.com> Date: Mon, 02 Apr 2012 13:56:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120316 Thunderbird/11.0 MIME-Version: 1.0 To: Tristan Gingold CC: Jack Howarth , gdb@sourceware.org Subject: Re: PR13901 References: <20120330134210.GA7869@bromo.med.uc.edu> <14D51CD4-4990-4B11-952C-64EB8F791306@adacore.com> In-Reply-To: <14D51CD4-4990-4B11-952C-64EB8F791306@adacore.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00006.txt.bz2 On 04/02/2012 12:57 PM, Tristan Gingold wrote: > On Apr 2, 2012, at 12:44 PM, Tristan Gingold wrote: >> > On Mar 30, 2012, at 3:42 PM, Jack Howarth wrote: >>> >> (gdb) break main >>> >> Breakpoint 1 at 0xd80: file himenoBMTxpa.c, line 71. >>> >> (gdb) r >>> >> Starting program: /Users/howarth/a.out >>> >> darwin_set_sstep: unknown flavour: 4 >>> >> Error calling thread_get_state for GP registers for thread 0x8451lxwarning: >>> >> Mach error at "i386-darwin-nat.c:118" in function >>> >> "i386_darwin_fetch_inferior_registers": (os/kern) invalid argument (0x4) >> > I now understand the issue: >> > >> > gdb spawns bash to run the program, but the bash spawned is 64 bits, which is not understood by gdb... > Fixed by this patch (committed on trunk): I don't know much about darwin/osx 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... Why does GDB need to touch the shell's registers at all in the first place? If we can't skip darwin_set_sstep for all continues that are not single-steps, 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: - /* Set single step. */ - inferior_debug (4, _("darwin_set_sstep (thread=%x, enable=%d)\n"), - thread->gdb_port, step); - darwin_set_sstep (thread->gdb_port, step); + /* Avoid touching the $SHELL process, and go straight to resuming it. */ + gdb_assert (!inf->private->starting_up || !step); + if (!inf->private->starting_up) + { + /* Set single step. */ + inferior_debug (4, _("darwin_set_sstep (thread=%x, enable=%d)\n"), + thread->gdb_port, step); + darwin_set_sstep (thread->gdb_port, step); WDYT? -- Pedro Alves