This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/2] gdbserver: catch fetch registers error
- From: Pedro Alves <palves at redhat dot com>
- To: "Metzger, Markus T" <markus dot t dot metzger at intel dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Cc: Daniel Jacobowitz <drow at false dot org>
- Date: Thu, 19 Jan 2017 15:02:10 +0000
- Subject: Re: [PATCH 1/2] gdbserver: catch fetch registers error
- Authentication-results: sourceware.org; auth=none
- References: <1481039697-17596-1-git-send-email-markus.t.metzger@intel.com> <1481039697-17596-2-git-send-email-markus.t.metzger@intel.com> <07c4f2ec-25b7-7a42-bc57-a64045a65f9e@redhat.com> <A78C989F6D9628469189715575E55B2340042017@IRSMSX104.ger.corp.intel.com>
On 01/19/2017 02:48 PM, Metzger, Markus T wrote:
> Hello Pedro,
>
> Thanks for the review and the elaborate response.
>
>> The case of trying to read registers from a thread that is
>> running is always a client bug. GDB should know which threads
>> it resumed, and checks like the validate_registers_access
>> you found should prevent such accesses reaching the server.
>
> That's a general misunderstanding of the design on my part, then. I typically
> don't check if I can/should do something but instead just do it and handle errors
> in case it failed. Like reading registers.
>
> Let me drop this patch and instead call validate_registers_access in btrace before
> reading the PC.
We have similar checks in other places, like e.g., frame.c:has_stack_frames.
Might make sense to factor things out a bit to avoid a throw/catch.
>> So it seems to me that btrace shouldn't even be trying to be enabled
>> on running threads.
>
> It works fine and I didn't see a reason why we would not want to allow it.
Sorry, that was bogus. I agree -- what it shouldn't be doing
is reading registers.
Thanks,
Pedro Alves