Re: [PATCH v2] [gdb/testsuite] Handle ptrace operation not permitted in can_spawn_for_attach

[Tom de Vries <tdevries@suse.de>]

On 4/24/24 21:40, Pedro Alves wrote:
> On 2024-04-18 07:32, Tom de Vries wrote:
>> When running the testsuite on a system with kernel.yama.ptrace_scope set to 1,
>> we run into attach failures.
>>
>> Fix this by recognizing "ptrace: Operation not permitted" in
>> can_spawn_for_attach.
>>
>> Tested on aarch64-linux.
> 
> I really don't like relying on "attach" 's behavior to decide whether to test attach.
> It's an inversion of responsibilities.
> 

Hi Pedro,

I don't see it that way, I think this approach accurately handles that 
if there's no permission to attach to a spawned process, you cannot 
spawn-for-attach.

> can_spawn_for_attach means "can I spawn a process, such that I will attach to it later", a
> simple atomic thing.
>  > Also, with this change, it means, "can I spawn a process and does 
attaching to it work?"
> So it ends up misnamed.
> 

I see what you mean, though I don't see it as misnamed, but if that 
bothers you I'm glad to rename it something else.  Can_spawn_and_attach? 
You have another suggestion?

> Someone tried to add something very much like this a while ago, and I objected then:
> 
>    https://inbox.sourceware.org/gdb-patches/e5f08136-fa4d-2f21-ff83-8adf4d3a158e@palves.net/
> > We ended up with gdb_attach, added in a7e6a19e87f3, which handles the 
"ptrace: Operation not permitted"
> scenarios too.  Some testcases have meanwhile been converted to use gdb_attach, but there are more,
> of course.  IMO we should continue that direction.  gdb_attach is not unlike "gdb_run_cmd" for example.
> 
> See also:
> 
>    https://inbox.sourceware.org/gdb-patches/3b845985-cbd4-4996-145e-14191338b095@polymtl.ca/
> 

I think the gdb_attach approach is problematic for the reasons that:
- it's not versatile enough to handle all the cases where it's needed,
   and
- it's required to be used in all the attach sites.

On the contrary, the proposed patch very simply handles all the cases, 
and in only one proc which is already used in a trivial way in most 
test-cases that need it.  So it seems obvious to me that the proposed 
solution is preferable.

Thanks,
- Tom