From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66294 invoked by alias); 4 Jan 2017 07:20:37 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 66275 invoked by uid 89); 4 Jan 2017 07:20:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=U*lgustavo, lgustavo@codesourcery.com, lgustavocodesourcerycom, sk:lgustav X-HELO: mga09.intel.com Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Jan 2017 07:20:26 +0000 Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP; 03 Jan 2017 23:20:23 -0800 X-ExtLoop1: 1 Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by fmsmga006.fm.intel.com with ESMTP; 03 Jan 2017 23:20:22 -0800 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.142]) by IRSMSX107.ger.corp.intel.com ([169.254.10.3]) with mapi id 14.03.0248.002; Wed, 4 Jan 2017 07:20:21 +0000 From: "Metzger, Markus T" To: Luis Machado , "gdb-patches@sourceware.org" CC: Daniel Jacobowitz , "Pedro Alves (palves@redhat.com)" Subject: RE: [ping] [PATCH 1/2] gdbserver: catch fetch registers error Date: Wed, 04 Jan 2017 07:20:00 -0000 Message-ID: References: In-Reply-To: Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00042.txt.bz2 > -----Original Message----- > From: Luis Machado [mailto:lgustavo@codesourcery.com] > Sent: Tuesday, January 3, 2017 7:29 PM > To: Metzger, Markus T ; gdb- > patches@sourceware.org > Cc: Daniel Jacobowitz ; Pedro Alves (palves@redhat.com) > > Subject: Re: [ping] [PATCH 1/2] gdbserver: catch fetch registers error Hi Luis, Thanks for your feedback. > >> When the PTRACE_PEEKUSER ptrace request to read registers fails, gdbse= rer > >> throws > >> an error that is caught in captured_main, where it causes a E01 error = packet to > >> be sent and gdbserer to quit (if --once was specified) or the event lo= op to be > >> re-started (otherwise). > >> > >> We may get such ptrace errors when trying to fetch registers for an ex= ited or > >> running thread. There are checks in GDB that check those conditions a= nd > throw > >> meaningful error messages before we could run into the above ptrace er= ror, > >> e.g. thread.c:validate_registers_access. > >> > >> I ran into a new case and, rather than adding another call to > >> validate_registers_access in GDB, I propose to catch the error already= when > >> handling the 'g' packet in gdbserver and reply with an error packet - = assuming > >> that gdbserver's internal state is still intact. > >> > >> To not replace a meaningful error message with E01, I'm trying to gene= rate a > >> useful error message when the error is detected and the exception is t= hrown. > >> > >> It would look like this ... > >> > >> gdb) PASS: gdb.btrace/enable-running.exp: continue to breakpoint: cont= to 44 > >> cont& > >> Continuing. > >> (gdb) PASS: gdb.btrace/enable-running.exp: cont& > >> record btrace > >> warning: Remote failure reply: E.Selected thread is running. > >> warning: Remote failure reply: E.Selected thread is running. > >> > >> ... although in this particular case, I'm going to suppress the warnin= g. > >> > >> To make this look a bit nicer, we could consider stripping the "E." or= the > >> entire "Remote failure reply: E." when (re-)throwing the error inside = GDB in > >> remote.c. [...]=20 > Is this a guaranteed recoverable scenario? I've seen GDB get confused > and mess up its internal state multiple times when it can't fetch > something essential like memory or registers. >=20 > So, even if we handle things gracefully in gdbserver, does GDB handle > that gracefully enough to carry on with a debugging session? At the moment, GDBserver quits or starts over. This is not recoverable as GDB doesn't have a clue that GDBserver just started over. This patch improves the situation by making GDBserver send an appropriate e= rror message to GDB and resume normally. It suffices in one concrete case (see = next patch in series). If in other cases GDB does not handle the error, I'd say= we fix GDB for those cases. Regards, Markus. Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928