Re: [FYI/pushed v4 03/25] Step over clone syscall w/ breakpoint, TARGET_WAITKIND_THREAD_CLONED

[Luis Machado <luis.machado@arm.com>]

On 11/14/23 16:29, Guinevere Larsen wrote:
> On 14/11/2023 14:26, Pedro Alves wrote:
>> Hi!
>>
>> On 2023-11-14 12:55, Guinevere Larsen wrote:
>>>> +gdb_test_multiple "catch syscall group:process" "catch process syscalls" {
>>>> +    -re "The feature \'catch syscall\' is not supported.*\r\n$gdb_prompt $" {
>>>> +    unsupported $gdb_test_name
>>>> +    return
>>>> +    }
>>>> +    -re ".*$gdb_prompt $" {
>>>> +    pass $gdb_test_name
>>>> +    }
>>>> +}
>>> In the clang buildbot we're getting this output:
>>>
>>> (gdb) catch syscall group:process
>>> warning: Can not parse XML syscalls information; XML support was disabled at compile time.
>>> Unknown syscall group 'process'.
>>> (gdb) PASS: gdb.threads/stepi-over-clone.exp: catch process syscalls
>>>
>>> This should be a failure, and should likely skip the next few tests.
>>>
>>> I don't know
>> Meh.  I guess we should make it UNSUPPORTED and bail.  But, really that is just
>> likely to make us not notice GDB wasn't built with XML support.  There's really no
>> good reason for that nowadays.  It's not like expat is a complicated dependency.
> 
> That's fair. I still think that test should read FAIL if we get an XML parse fail, but maybe this isn't the place to leave early.
> 
> I gave it some more thought, and I think the best place would be after the test builds the list of syscalls, if that list is empty there is no point in further testing, since no breakpoints will ever be set. I think a better the point to bail would be right before the main loop, since its unlikely we get an empty list at that point without a previous failure. Bonus points, we don't get tons of timeout-based errors, speeding up testing.
> 
>>
>> That buildbot should be fixed to configure gdb with libexpat available, IMO.

Before that, should we agree on making libexpat a required dependency for gdb? Some targets (aarch64-linux for one) won't work properly without XML support.

Unfortunately I don't think that is clear at the moment. Those of us developing gdb know what the message means, but more unfamiliar users may not know.

> 
> You're right, and I'll try to do that. Do we need some specific configure option? or is it just that the container (probably) doesn't have expat and thus configure is automatically skipping it?
> 
> I think the test could be improved either way.
> 
>>
>> Or could it be that expat is supposedly available but it fails to build with Clang?
>> That would be very surprising, though.
>>
> More of an FIY than anything. The "clang" buildbot still builds GDB with gcc, it just uses clang for the testsuite, so it's not about expat problems with clang.
>