[Toybox] [PATCH] strace: initial commit.

[enh]

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.)

On Fri, Sep 17, 2021 at 3:46 PM enh <enh at google.com> wrote:

> This is most notably lacking -p and -f, and only covers a small subset
> of system calls, but it's "useful" in the sense that you can strace
> something like toybox date, say, and see everything.
>
> There's a fundamental assumption here that we don't need to worry about
> multiple personalities. (This is what makes "real" strace's build so
> complex, and why Android has _never_ actually shipped a fully correct
> strace build.) Given that the desktop's already been 64-bit only
> for a while, microcontrollers are likely to stay 32-bit only for a
> while, and the odd one out -- mobile -- is moving to be 64-bit only
> (https://www.arm.com/blogs/blueprint/64-bit), so by the time this is
> ready to graduate from pending, I'm assuming no-one will care!
> ---
>  lib/portability.h     |   2 +
>  toys/pending/strace.c | 618 ++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 620 insertions(+)
>  create mode 100644 toys/pending/strace.c
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20210917/8a9ef4f5/attachment-0001.htm>