(though that also means we can #include <linux/elf.h> instead of the "full" elf.h...)
On Fri, Jan 27, 2023, 07:30 enh <e...@google.com> wrote: > > > On Thu, Jan 26, 2023 at 11:03 PM Rob Landley <r...@landley.net> wrote: > >> 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? >> > > NT_PRSTATUS. > > looking at the uapi elf.h, it looks like that is just 1 on every > architecture... > > >> 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
