[Toybox] [PATCH] strace: initial commit.

[enh]

well, not wanting worms everywhere is one reason i've sat on this so long.
but at the same time, i do keep finding myself with an ioctl that strace
won't decode, and no non-GPL strace to add it to. so this helps with that
at least.

of course, i see even disabled this managed to break the mac build in
github CI, so i've sent a fix for that that foreshadows at least some of
the work needed to make this work for arm too! (it won't just have been
macOS that was broken: any target where there isn't a `struct
user_regs_struct` or where it's called something different -- like
Linux/arm -- will have broken.)

On Fri, Sep 17, 2021 at 8:36 PM Rob Landley <rob at landley.net> wrote:

> On 9/17/21 5:54 PM, enh via Toybox wrote:
> > i know when rob's talked about "toybox strace", he meant one with no
> decoding,
> > just raw numbers. that doesn't really let me replace "real" strace
> though (which
> > was already a PITA to update, and switched to GPL a year or two back
> anyway).
> > the hope here is to show that we can actually decode without being _too_
> > large/complicated...
> >
> > the TODO about cases where glibc doesn't use the same structs as the
> kernel
> > points to one of the hairiest issues, plus this would be the first toy
> where we
> > actually need to add a few lines of code for *every* architecture that
> we want
> > "allyesconfig" to build on. i haven't even added arm/arm64 yet! (but i
> will do
> > so if this gets committed.)
>
> This was on my post-1.0 todo list for a reason, but if you wanna open this
> can
> of worms... :)
>
> Applied.
>
> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20210920/c35a15d4/attachment-0001.htm>