<div dir="auto">(though that also means we can #include <linux/elf.h> instead of the "full" elf.h...)</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 27, 2023, 07:30 enh <<a href="mailto:enh@google.com">enh@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 26, 2023 at 11:03 PM Rob Landley <<a href="mailto:rob@landley.net" target="_blank" rel="noreferrer">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 1/26/23 16:44, enh via Toybox wrote:<br>
> The man page's threat that not all architectures will have PTRACE_GETREGS<br>
> is true... Also #if more optional legacy system calls and arguments, add<br>
> getrandom() flag decoding, and remove a stray unused global.<br>
<br>
What needed elf.h? (We avoided using it in other contexts. I don't remember what<br>
specifically was wrong with it, but I remember it being problematic. And not<br>
actually defining anything useful.) Looks like it's there on everything but<br>
MacOS now?<br></blockquote><div><br></div><div>NT_PRSTATUS.</div><div><br></div><div>looking at the uapi elf.h, it looks like that is just 1 on every architecture...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I expect my reflexive wince (other than #including a non-linux/ header from a<br>
command instead of toys.h or portability.h) is largely due to the Linux x86-64<br>
architecture devs pulling ELF shenanigans. They decided that x86-64 would<br>
uniquely depend on an external implementation of ELF plumbing as a build<br>
dependency (uniquely as in even i686 can build without it) when the kernel<br>
already exports multiple elf headers (such as include/uapi/linux/elf.h), has TWO<br>
elf parsers (fs/binfmt_elf.c and fs/binfmt_elf_fdpic.c, sort of an<br>
ext2/ext3/ext4 drivers being separate thing), and I've stumbled over other ELF<br>
plumbing in the kernel over the years...<br>
<br>
<a href="https://lkml.iu.edu/hypermail/linux/kernel/2110.3/00278.html" rel="noreferrer noreferrer" target="_blank">https://lkml.iu.edu/hypermail/linux/kernel/2110.3/00278.html</a><br>
<br>
It's trivial to patch out:<br>
<br>
<a href="https://landley.net/toybox/downloads/binaries/mkroot/0.8.9/linux-patches/0002-X86-64-should-not-uniquely-require-a-third-ELF-packa.patch" rel="noreferrer noreferrer" target="_blank">https://landley.net/toybox/downloads/binaries/mkroot/0.8.9/linux-patches/0002-X86-64-should-not-uniquely-require-a-third-ELF-packa.patch</a><br>
<br>
But it's an ongoing nuisance because vanilla still demands it...<br>
<br>
Rob<br>
</blockquote></div></div>
</blockquote></div>