Re: [PATCH] [gdb/tdep] Backport i386_canonicalize_syscall rewrite to gdb-16-branch

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

On 3/13/25 13:40, Guinevere Larsen wrote:
> On 3/13/25 6:53 AM, Tom de Vries wrote:
>> Commit fbfb29b304e ("[gdb/tdep] Rewrite i386_canonicalize_syscall") fixes
>> PR32770, which reproduces on the gdb-16-branch, but the commit is not 
>> ideal
>> for backporting because it completely rewrites i386_canonicalize_syscall.
>>
>> Instead, this is a version of the patch that adds a single line entry 
>> for each
>> syscall value for which i386_canonicalize_syscall gives a different 
>> result
>> with and without the patch.
>>
>> Consequently, the two versions give identical results.  I've checked 
>> this for
>> syscalls 0 to 466.
>>
>> Tested on x86_64-linux with target board unix/-m32, on top of gdb-16- 
>> branch.
>>
>> PR tdep/32770
>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32770
>> ---
> 
> Hi!
> 
> I looked over all the special cases, and it mostly looks ok. There are 
> quite a few syscalls where we have an older or similar enough version, 
> like execveat and execve, or faccessat and faccessat2, but I can see 
> from the accept4 patch why you wouldn't have done that... however, for 
> the semtimedop_time64 syscall, you just converted to the semtimedop 
> version. What is special about that one?
> 

Good question.

This was one of the syscalls I came across while reviewing the 
gdb_syscall enum values >= 500.  And since the recording support doesn't 
actually record the timeout parameter, the time64 part of 
semtimedop_time64 seemed irrelevant.

So, what was special here was that gdb_sys_semtimedop was supported, but 
there was no corresponding mapping from i386.

For the execveat case, gdb_sys_execveat is missing.  That makes it 
similar to the accept4 case.

I hope that answers your question.

Thanks,
- Tom