<div dir="ltr">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.<div><br></div><div>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.)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 17, 2021 at 8:36 PM Rob Landley <<a href="mailto:rob@landley.net">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 9/17/21 5:54 PM, enh via Toybox wrote:<br>
> i know when rob's talked about "toybox strace", he meant one with no decoding,<br>
> just raw numbers. that doesn't really let me replace "real" strace though (which<br>
> was already a PITA to update, and switched to GPL a year or two back anyway).<br>
> the hope here is to show that we can actually decode without being _too_<br>
> large/complicated...<br>
> <br>
> the TODO about cases where glibc doesn't use the same structs as the kernel<br>
> points to one of the hairiest issues, plus this would be the first toy where we<br>
> actually need to add a few lines of code for *every* architecture that we want<br>
> "allyesconfig" to build on. i haven't even added arm/arm64 yet! (but i will do<br>
> so if this gets committed.)<br>
<br>
This was on my post-1.0 todo list for a reason, but if you wanna open this can<br>
of worms... :)<br>
<br>
Applied.<br>
<br>
Rob<br>
</blockquote></div>