I would use either the kernel interface:
arch/x86/kernel/process_64.c
961 SYSCALL_DEFINE2(arch_prctl, int, option, unsigned long, arg2)
Where is seems to what most caller do, or maybe something like:
union __arch_prctl_arg
{
unsigned long addr;
unsigned long *vaddr;
};
int arch_prctl (int option, union __arch_prctl_arg *arg);
The variadic syscall wrapper has caused some trouble in the past,
so it would be wise to avoid it.
And for constants, it would require a x86_64 specific sys/prctl.h header
with either the has_include tricks to include the kernel one or to just
copy the kernel one (along with possible a test to check the sync with
kernel definitions).
On 21/08/24 15:09, enh wrote:
> it also looks like the relevant constants (such as ARCH_SET_FS) are
> only exposed in <asm/prctl.h>, which isn't currently transitively
> included from <sys/prctl.h>...
>
> On Wed, Aug 21, 2024 at 1:59 PM enh <enh@xxxxxxxxxx> wrote:
>>
>> i wonder if part of the problem was wondering what the signature should be?
>>
>> arch_prctl() sets architecture-specific process or thread state.
>> op selects an operation and passes argument addr to it; addr is
>> interpreted as either an unsigned long for the "set" operations,
>> or as an unsigned long *, for the "get" operations.
>>
>> On Wed, Aug 21, 2024 at 1:39 PM Adhemerval Zanella Netto
>> <adhemerval.zanella@xxxxxxxxxx> wrote:
>>>
>>>
>>>
>>> On 21/08/24 14:02, enh wrote:
>>>> i see glibc has a _symbol_ for arch_prctl(), but there's nothing in
>>>> the headers? a variety of projects seem to `extern` it themselves so
>>>> they can use the glibc symbol, even though the man page denies that it
>>>> exists and suggests you use syscall() instead.
>>>>
>>>> is this half-existence deliberate, or should it be fixed one way or
>>>> the other (adding the header declaration or removing the symbol)?
>>>>
>>>> i notice musl is the same, but i assume that's just for glibc
>>>> compatibility rather than an actual decision on their part.
>>>>
>>>> before i copy the same oddity in bionic for
>>>> https://blog.chromium.org/2024/06/building-faster-smarter-chromebook.html
>>>> i thought i'd at least _ask_ :-)
>>>>
>>>
>>> It seems to be a overlook from when it was originally added (a47fd6810cb).
>>> I think we should add a x86 sys/prctl.h with the definition.
