This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v2] Improve ptrace-error detection on Linux targets
- From: Pedro Alves <palves at redhat dot com>
- To: Sergio Durigan Junior <sergiodj at redhat dot com>
- Cc: GDB Patches <gdb-patches at sourceware dot org>, Eli Zaretskii <eliz at gnu dot org>, Ruslan Kabatsayev <b7 dot 10110111 at gmail dot com>
- Date: Wed, 4 Sep 2019 21:35:19 +0100
- Subject: Re: [PATCH v2] Improve ptrace-error detection on Linux targets
- References: <20190819032918.3536-1-sergiodj@redhat.com> <20190826183205.19008-1-sergiodj@redhat.com> <28c4f743-91f1-59c3-83ff-3f791811f996@redhat.com> <87mufrai1z.fsf@redhat.com> <ca41b317-cf1c-dfde-9f54-f990acf19dc5@redhat.com> <87zhjjrh7n.fsf@redhat.com> <ddad50df-c7c2-d3b2-d605-6a3a77885ee8@redhat.com> <87d0gfrewj.fsf@redhat.com>
On 9/4/19 9:21 PM, Sergio Durigan Junior wrote:
>> or extended-remote + "(gdb) attach" ?
> I'm trying to come up with a way to test this. The only way would be to
> make gdbserver successfully start so that we could perform an
> extended-remote connection from GDB. However, if gdbserver starts
> without problems, this means that the ptrace check succeeded and that
> there are no ptrace restrictions in place. Therefore, an "attach" would
> succeed as well. Which means that even if we're running GDB in a
> ptrace-restricted system, things will go OK as long as gdbserver is not
> restricted. In this case, we wouldn't see any error messages IIUC.
So
$ gdbserver --multi :9999
exits with error immediately?
You could start gdbserver with the restrictions off (like a long
lived daemon), and then while gdbserver is running enable
restrictions, I suppose.
Thanks,
Pedro Alves