On 1/26/23 16:44, enh via Toybox wrote: > The man page's threat that not all architectures will have PTRACE_GETREGS > is true... Also #if more optional legacy system calls and arguments, add > getrandom() flag decoding, and remove a stray unused global.
What needed elf.h? (We avoided using it in other contexts. I don't remember what specifically was wrong with it, but I remember it being problematic. And not actually defining anything useful.) Looks like it's there on everything but MacOS now? I expect my reflexive wince (other than #including a non-linux/ header from a command instead of toys.h or portability.h) is largely due to the Linux x86-64 architecture devs pulling ELF shenanigans. They decided that x86-64 would uniquely depend on an external implementation of ELF plumbing as a build dependency (uniquely as in even i686 can build without it) when the kernel already exports multiple elf headers (such as include/uapi/linux/elf.h), has TWO elf parsers (fs/binfmt_elf.c and fs/binfmt_elf_fdpic.c, sort of an ext2/ext3/ext4 drivers being separate thing), and I've stumbled over other ELF plumbing in the kernel over the years... https://lkml.iu.edu/hypermail/linux/kernel/2110.3/00278.html It's trivial to patch out: https://landley.net/toybox/downloads/binaries/mkroot/0.8.9/linux-patches/0002-X86-64-should-not-uniquely-require-a-third-ELF-packa.patch But it's an ongoing nuisance because vanilla still demands it... Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
