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 <r...@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 >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net