Message ID | 1fdb87a3328423d35fda3d45bdf54fa11bb8d82c.1543317060.git.andrew.burgess@embecosm.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 69001 invoked by alias); 27 Nov 2018 11:13:21 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 68869 invoked by uid 89); 27 Nov 2018 11:13:20 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=HX-HELO:sk:mail-wm, HX-Google-DKIM-Signature:6WVQ X-HELO: mail-wm1-f44.google.com Received: from mail-wm1-f44.google.com (HELO mail-wm1-f44.google.com) (209.85.128.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Nov 2018 11:13:18 +0000 Received: by mail-wm1-f44.google.com with SMTP id q26so21657659wmf.5 for <gdb-patches@sourceware.org>; Tue, 27 Nov 2018 03:13:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :in-reply-to:references; bh=lfkoiw1tjdZ8J3NkfVbrywo2bZZ98M9X0AAQE3zj8mM=; b=b2isGO9mjr2FHXHzDYcqQZUpUlf4AbTFjPk5r95A0pvvQiXXhq6NKqcXeDm3EbdbZj /egjvOvQAGZcnaMWk6MyFIDTQE1m6nSDuavzSxOpoM6I+Rv07AznR1gwOrhVA17puMOJ 6APyakXbRgjitQVz85H9aG7BmoB2AZ11W6PgHWnHSZvJGvRvqsxdSw1fJrwW4XBBMydv /GQj3rjYOoljEPCRCj+eJIua66vvL9FAlOvad9Ck0l8foodeQs4UohL9S3l5SkbNIODe a6gXu7dT+ndrj1OG0gzfl7FXL4ijR0QW43dwAN2yunHhaoUrH8n+YE8XoUqL0su9hGf9 DdQA== Return-Path: <andrew.burgess@embecosm.com> Received: from localhost (host86-156-236-171.range86-156.btcentralplus.com. [86.156.236.171]) by smtp.gmail.com with ESMTPSA id e8-v6sm7971161wmf.22.2018.11.27.03.13.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 27 Nov 2018 03:13:14 -0800 (PST) From: Andrew Burgess <andrew.burgess@embecosm.com> To: gdb-patches@sourceware.org Cc: Simon Marchi <simark@simark.ca>, Andrew Burgess <andrew.burgess@embecosm.com> Subject: [PATCHv2 2/3] gdb/regcache: When saving, ignore registers that can't be read Date: Tue, 27 Nov 2018 11:13:05 +0000 Message-Id: <1fdb87a3328423d35fda3d45bdf54fa11bb8d82c.1543317060.git.andrew.burgess@embecosm.com> In-Reply-To: <cover.1543317060.git.andrew.burgess@embecosm.com> References: <cover.1543317060.git.andrew.burgess@embecosm.com> In-Reply-To: <cover.1543317060.git.andrew.burgess@embecosm.com> References: <cda98bb2-ff4b-09fd-9b04-ec5523dcb49c@simark.ca> <cover.1543317060.git.andrew.burgess@embecosm.com> X-IsSubscribed: yes |
Commit Message
Andrew Burgess
Nov. 27, 2018, 11:13 a.m. UTC
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. 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, 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. gdb/ChangeLog: * regcache.c (reg_buffer::save): When saving the current register state, ignore registers that can't be read. --- gdb/ChangeLog | 5 +++++ gdb/regcache.c | 12 +++++++++++- 2 files changed, 16 insertions(+), 1 deletion(-)
Comments
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
* Pedro Alves <palves@redhat.com> [2018-11-27 12:41:51 +0000]: > 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? Pedro, Thanks for taking the time to review this patch. Just wanted to confirm that (subject to review) the above feedback doesn't prevent patch #1 or #3 being merged, correct? Patch #1 specifically makes the inferior call error rather than assert, which feels like it doesn't raise the same concerns you discuss above. Thanks, Andrew
On 11/27/2018 03:30 PM, Andrew Burgess wrote: > Thanks for taking the time to review this patch. > > Just wanted to confirm that (subject to review) the above feedback > doesn't prevent patch #1 or #3 being merged, correct? Correct. > Patch #1 specifically makes the inferior call error rather than > assert, which feels like it doesn't raise the same concerns you > discuss above. Absolutely. Thanks, Pedro Alves
diff --git a/gdb/regcache.c b/gdb/regcache.c index 6e0e8c3e7e0..c9503295f59 100644 --- a/gdb/regcache.c +++ b/gdb/regcache.c @@ -277,7 +277,17 @@ reg_buffer::save (register_read_ftype cooked_read) if (gdbarch_register_reggroup_p (gdbarch, regnum, save_reggroup)) { gdb_byte *dst_buf = register_buffer (regnum); - enum register_status status = cooked_read (regnum, dst_buf); + enum register_status status; + + TRY + { + status = cooked_read (regnum, dst_buf); + } + CATCH (ex, RETURN_MASK_ERROR) + { + status = REG_UNAVAILABLE; + } + END_CATCH gdb_assert (status != REG_UNKNOWN);