[Toybox] [PATCH] strace.c: add risc-v support, fix non-legacy architectures.

[enh]

On Thu, Jan 26, 2023 at 11:03 PM Rob Landley <rob at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20230127/c0773b1d/attachment.htm>