From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24463 invoked by alias); 27 Nov 2018 12:41:56 -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 24452 invoked by uid 89); 27 Nov 2018 12:41:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=observing, gracefully X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Nov 2018 12:41:54 +0000 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0591730820CE; Tue, 27 Nov 2018 12:41:53 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 351901001938; Tue, 27 Nov 2018 12:41:51 +0000 (UTC) Subject: Re: [PATCHv2 2/3] gdb/regcache: When saving, ignore registers that can't be read To: Andrew Burgess , gdb-patches@sourceware.org References: <1fdb87a3328423d35fda3d45bdf54fa11bb8d82c.1543317060.git.andrew.burgess@embecosm.com> Cc: Simon Marchi From: Pedro Alves Message-ID: <130a11fc-540f-6393-7665-f3f047561887@redhat.com> Date: Tue, 27 Nov 2018 12:41:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1fdb87a3328423d35fda3d45bdf54fa11bb8d82c.1543317060.git.andrew.burgess@embecosm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-11/txt/msg00457.txt.bz2 On 11/27/2018 11:13 AM, Andrew Burgess wrote: > The previous commit addressed an assertion that could trigger if a > target threw an error while saving state ahead of an inferior function > call. > > The specific case that highlighted this issue was a RISC-V target that > claimed to support floating point registers, but when GDB tried to > read a floating point register the remote sent back an error. > > With the previous commit we no longer see an assertion for this > target, now GDB abandons the inferior function call. > > Although this is slightly better, it feels like for this specific case > GDB could do even better. If during a call to reg_buffer::save GDB > encounters an error trying to read a register then GDB should simply > mark the register as unavailable and carry on. The consequence of > marking the register unavailable is that GDB will not then try to > restore the register once the inferior function call is complete. I'm skeptical about this. It sounds risky to me. An infcall is potentially state-destructive, and silencing errors just seems like asking for trouble. Particularly, while you're observing one specific error, you're swallowing all kinds of errors. > > What I haven't done in this commit is provide any user feedback that > GDB would like to backup a particular register, but can't. Right now > I figure that if the user cares about this they would probably try 'p > $reg_name' themselves, How is the user to know to do that without any kind of indication? > at which point it becomes obvious that the > register can't be read. That said, I'm open to adding a warning that > the register failed to save if that is thought important. > > I've tested this using on X86-64/Linux native, and for > native-gdbserver with no regressions. Against my miss-behaving target > I can now make inferior calls without any problems. > I'm really not sure this is a good trade off. How could such a stub with this kind of problem end up in production? It sounds like it can't have seen much wild use without someone running into this. Making GDB handle this scenario "gracefully" can only be useful if this is really a kind of problem that can go undetected for a long while and you plan on continuing to let users use the "bad" stub. But what's the real scenario that would lead to that happening? Thanks, Pedro Alves