From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100123 invoked by alias); 4 Jan 2017 15:49:39 -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 100101 invoked by uid 89); 4 Jan 2017 15:49:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=january, January X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Jan 2017 15:49:27 +0000 Received: from svr-orw-mbx-03.mgc.mentorg.com ([147.34.90.203]) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1cOnoa-0003Oy-Er from Luis_Gustavo@mentor.com ; Wed, 04 Jan 2017 07:49:24 -0800 Received: from [172.30.9.137] (147.34.91.1) by svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 4 Jan 2017 07:48:43 -0800 Reply-To: Luis Machado Subject: Re: [ping] [PATCH 1/2] gdbserver: catch fetch registers error References: To: "Metzger, Markus T" , "gdb-patches@sourceware.org" CC: Daniel Jacobowitz , "Pedro Alves (palves@redhat.com)" From: Luis Machado Message-ID: <13bfe2b3-6f22-5673-83d7-5ab3d9210a0e@codesourcery.com> Date: Wed, 04 Jan 2017 15:49:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: svr-orw-mbx-01.mgc.mentorg.com (147.34.90.201) To svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00054.txt.bz2 On 01/04/2017 01:20 AM, Metzger, Markus T wrote: >> -----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, gdbserer >>>> 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 loop to be >>>> re-started (otherwise). >>>> >>>> We may get such ptrace errors when trying to fetch registers for an exited or >>>> running thread. There are checks in GDB that check those conditions and >> throw >>>> meaningful error messages before we could run into the above ptrace error, >>>> 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 generate a >>>> useful error message when the error is detected and the exception is thrown. >>>> >>>> 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 warning. >>>> >>>> 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. > [...] >> 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. >> >> 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 error > 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. I missed the second entry in the series. I'll check it.