public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Matheus Afonso Martins Moreira <matheus.a.m.moreira@gmail.com>
To: gcc@gcc.gnu.org
Subject: [RFC] Linux system call builtins
Date: Tue, 09 Apr 2024 23:59:50 -0300	[thread overview]
Message-ID: <acf3fb5a2348daf568cead2f3f1e321e@gmail.com> (raw)
In-Reply-To: <ZhUqaVDkVGKkSAyj@arm.com>

> note: some syscalls / features don't work without asm
> (posix thread cancellation, vfork, signal return,..)

That's true. On the other hand, POSIX compliance
is not always a goal or a requirement.

> and using raw syscalls outside of the single runtime the
> application is using is problematic (at least on linux).

I understand why their use is problem on other operating systems:
since the ABI is not actually stable, programs will break eventually.

Why do you say they are problematic on Linux though? Please elaborate.

The ABI being stable should mean that I can for example
strace a program, analyze the system calls and implement
a new version of it that performs the same functions.

> where should the syscall be if not in a library like libc?

In the compiler. It should be able to generate the system call code.

> clone cannot even be used from c code in general
> as CLONE_VM is not compatible with c semantics
> without a new stack (child clobbers the parent stack)
> so the c builtin would not always work
> it is also a syscall that only freestanding
> application can use not something that calls
> into the libc

There are major projects out there which do use it regardless.
For example, systemd:

https://github.com/systemd/systemd/blob/main/src/basic/raw-clone.h
https://github.com/systemd/systemd/blob/main/src/shared/async.h
https://github.com/systemd/systemd/blob/main/src/shared/async.c
https://github.com/systemd/systemd/blob/main/docs/CODING_STYLE.md

> even in a freestanding application it is tricky to use right

No argument from me there. It is tricky...
The compiler should make it possible though.

> so i don't see why clone is the quintessential example.

I think it is the best example because attempting to use clone
is not actually supported by glibc.

https://sourceware.org/bugzilla/show_bug.cgi?id=10311

"If you use clone() you're on your own."

> my main worry is that the builtins encourage
> the use of raw syscalls and outside of libc
> development it is not well understood how to
> do that correctly

I don't think their use should be discouraged.
Linux system calls, at least.
The ones of other operating systems most definitely should.
Using them leads to breakage since the ABI is not stable.
The developers of the go programming language can attest to that.

> i guess it's ok if it is by default an error
> outside of -ffreestanding.

Hosted C programs could also make good use of them.
They could certainly start out exclusive to freestanding C
and then made available to general code if there's demand.

  reply	other threads:[~2024-04-10  2:59 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-08  9:19 Matheus Afonso Martins Moreira
2024-04-08  9:58 ` Jonathan Wakely
2024-04-08 11:59   ` Matheus Afonso Martins Moreira
2024-04-08 14:00     ` Jonathan Wakely
2024-04-08 11:24 ` Florian Weimer
2024-04-08 11:44   ` Alexander Monakov
2024-04-08 11:50     ` Florian Weimer
2024-04-08 13:01       ` Alexander Monakov
2024-04-08 13:37   ` Matheus Afonso Martins Moreira
2024-04-08 18:18 ` Paul Iannetta
2024-04-08 18:26   ` Andrew Pinski
2024-04-08 20:01     ` Paul Iannetta
2024-04-08 20:20       ` Paul Koning
2024-04-10  1:48     ` Matheus Afonso Martins Moreira
2024-04-10 13:15       ` Paul Koning
2024-04-10 14:10         ` Matheus Afonso Martins Moreira
2024-04-10  1:26   ` Matheus Afonso Martins Moreira
2024-04-08 20:24 ` Paul Floyd
2024-04-10  2:19   ` Matheus Afonso Martins Moreira
2024-04-09 11:45 ` Szabolcs Nagy
2024-04-10  2:59   ` Matheus Afonso Martins Moreira [this message]
2024-04-10 11:04     ` Szabolcs Nagy
2024-04-10 14:00       ` Matheus Afonso Martins Moreira

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=acf3fb5a2348daf568cead2f3f1e321e@gmail.com \
    --to=matheus.a.m.moreira@gmail.com \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).