[v3,2/3] Add an optional "alias" attribute to syscall entries.

  On 11/28/18 9:44 AM, Eli Zaretskii wrote:
>> Cc: gdb-patches@sourceware.org
>> From: John Baldwin <jhb@FreeBSD.org>
>> Date: Wed, 28 Nov 2018 09:22:22 -0800
>>
>> Yes, I think this is better as well.  Eli, I don't know if other OS's will
>> make use of this feature.  Given Pedro's new text above, do you think it
>> should still be moved into a native section or should it stay in the the
>> syscall section?
> 
> I question the need to make this text more general than this feature
> will ever become.  But if Pedro thinks we will have similar aliases on
> other OSes, then sure, do it as Pedro suggests.

Oh, I was just referring to Pedro's version being shorter.  I'm fine with
moving it.  This is a bit longer as it restores a bit of the FreeBSD-specific
note about syscall ABIs but that seemed relevant when moving it:
  

> Cc: palves@redhat.com, gdb-patches@sourceware.org
> From: John Baldwin <jhb@FreeBSD.org>
> Date: Wed, 28 Nov 2018 10:00:48 -0800
> 
> Oh, I was just referring to Pedro's version being shorter.  I'm fine with
> moving it.  This is a bit longer as it restores a bit of the FreeBSD-specific
> note about syscall ABIs but that seemed relevant when moving it:
> 
> diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
> index 944a2c4383..c60c2b80c4 100644
> --- a/gdb/doc/gdb.texinfo
> +++ b/gdb/doc/gdb.texinfo
> @@ -22329,6 +22329,7 @@ configurations.
>  * Cygwin Native::		Features specific to the Cygwin port
>  * Hurd Native::                 Features specific to @sc{gnu} Hurd
>  * Darwin::			Features specific to Darwin
> +* FreeBSD::			Features specific to FreeBSD
>  @end menu
>  
>  @node BSD libkvm Interface
> @@ -23214,6 +23215,26 @@ better understand the cause of a fault.  The default is off.
>  Show the current state of exceptions trapping.
>  @end table
>  
> +@node FreeBSD
> +@subsection FreeBSD
> +@cindex FreeBSD
> +
> +When the ABI of a system call is changed in the FreeBSD kernel, this
> +is implemented by leaving a compatibility system call using the old
> +ABI at the existing number and allocating a new system call number for
> +the version using the new ABI.  As a convenience, when a system call
> +is caught by name, compatibility system calls are also caught.
> +
> +For example, FreeBSD 12 introduced a new variant of the @code{kevent}
> +system call and catching the @code{kevent} system call by name catches
> +both variants:
> +
> +@smallexample
> +(@value{GDBP}) catch syscall kevent
> +Catchpoint 1 (syscalls 'freebsd11_kevent' [363] 'kevent' [560])
> +(@value{GDBP})
> +@end smallexample

This is fine with me, but let's hear what Pedro thinks.
  

On 11/28/2018 06:00 PM, John Baldwin wrote:
> On 11/28/18 9:44 AM, Eli Zaretskii wrote:
>>> Cc: gdb-patches@sourceware.org
>>> From: John Baldwin <jhb@FreeBSD.org>
>>> Date: Wed, 28 Nov 2018 09:22:22 -0800
>>>
>>> Yes, I think this is better as well.  Eli, I don't know if other OS's will
>>> make use of this feature.  Given Pedro's new text above, do you think it
>>> should still be moved into a native section or should it stay in the the
>>> syscall section?
>>
>> I question the need to make this text more general than this feature
>> will ever become.  But if Pedro thinks we will have similar aliases on
>> other OSes, then sure, do it as Pedro suggests.

Don't other BSD kernels do something similar?

I think Linux always adds new syscalls under a new name, even if the
old replaced one is deprecated.

> Oh, I was just referring to Pedro's version being shorter.  I'm fine with
> moving it.  This is a bit longer as it restores a bit of the FreeBSD-specific
> note about syscall ABIs but that seemed relevant when moving it:
I'm fine with it as well.  It just felt like if the we could keep it short, it'd
avoid fragmenting the information.  IMO, a user reading the "catch syscall"
bits in the manual isn't going to remember to look up the FreeBSD-specific info
in a different node.  Unless we add some xrefs.

Thanks,
Pedro Alves
  

On 11/28/18 10:34 AM, Pedro Alves wrote:
> On 11/28/2018 06:00 PM, John Baldwin wrote:
>> On 11/28/18 9:44 AM, Eli Zaretskii wrote:
>>>> Cc: gdb-patches@sourceware.org
>>>> From: John Baldwin <jhb@FreeBSD.org>
>>>> Date: Wed, 28 Nov 2018 09:22:22 -0800
>>>>
>>>> Yes, I think this is better as well.  Eli, I don't know if other OS's will
>>>> make use of this feature.  Given Pedro's new text above, do you think it
>>>> should still be moved into a native section or should it stay in the the
>>>> syscall section?
>>>
>>> I question the need to make this text more general than this feature
>>> will ever become.  But if Pedro thinks we will have similar aliases on
>>> other OSes, then sure, do it as Pedro suggests.
> 
> Don't other BSD kernels do something similar?

Hmm, it is true that 4.4BSD itself included some compat system calls to handle
some ABI changes which is why the BSD's follow that model.  NetBSD at least
follows FreeBSD's model of renaming old system calls and adding new numbers for
new ABIs.  OpenBSD kind of does, but it retires older ABIs more aggressively
and seems to reuse old numbers unlike FreeBSD and NetBSD.

> I think Linux always adds new syscalls under a new name, even if the
> old replaced one is deprecated.
> 
>> Oh, I was just referring to Pedro's version being shorter.  I'm fine with
>> moving it.  This is a bit longer as it restores a bit of the FreeBSD-specific
>> note about syscall ABIs but that seemed relevant when moving it:
> I'm fine with it as well.  It just felt like if the we could keep it short, it'd
> avoid fragmenting the information.  IMO, a user reading the "catch syscall"
> bits in the manual isn't going to remember to look up the FreeBSD-specific info
> in a different node.  Unless we add some xrefs.

Yes, that is why I started with it in the syscall section.
  

> Cc: gdb-patches@sourceware.org
> From: Pedro Alves <palves@redhat.com>
> Date: Wed, 28 Nov 2018 18:34:42 +0000
> 
> IMO, a user reading the "catch syscall" bits in the manual isn't
> going to remember to look up the FreeBSD-specific info in a
> different node.  Unless we add some xrefs.

Then let's add them.