Re: [PATCH v2 3/7] syscall.h: add syscall_set_arguments() and syscall_set_return_value()
Eugene Syromyatnikov <[email protected]>
| Newsgroups | gmane.linux.ports.hexagon,gmane.comp.sysutils.strace.devel,gmane.linux.kernel.arc,gmane.linux.kernel,gmane.linux.ports.arm.kernel,gmane.linux.ports.mips,gmane.linux.ports.parisc,gmane.linux.ports.ppc64.devel,gmane.linux.ports.riscv,gmane.linux.ports.sh.devel,gmane.linux.ports.sparc,gmane.linux.uml.devel,gmane.linux.kernel.cross-arch |
|---|---|
| Message-ID | <CACGkJdtAmtxsPiKYUzLLmfNGf6oJ9YS-25ZY9VvEEWhz37Qx6Q@mail.gmail.com> |
On Fri, Jan 17, 2025 at 2:03 AM H. Peter Anvin <[email protected]> wrote: > > I link the concept of this patchset, but *please* make it clear in the > comments that this does not solve the issue of 64-bit kernel arguments > on 32-bit systems being ABI specific. Sorry, but I don't see how this is relevant; each architecture has its own ABI with its own set of peculiarities, and there's a lot of (completely unrelated) work needed in order to make an ABI that is architecture-agnostic. All this patch set does is provides a consistent way to manipulate scno and args across architectures; it doesn't address the fact that some architectures have mmap2/mmap_pgoff syscall, or that some have fadvise64_64 in addition to fadvise64, or the existence of clone2, or socketcall, or ipc; or that some architectures don't have open or stat; or that scnos on different architectures or even different bit-widths within the "same" architecture are different. > This isn't unique to this patch in any way; the only way to handle it is > by keeping track of each ABI. That's true, but this patch doesn't even try to address that. -- Eugene Syromyatnikov mailto:[email protected] xmpp:esyr@jabber.{ru|org}