[Toybox] [PATCH] strace: fix m68k build.

[Rob Landley]

On 12/3/21 7:38 PM, enh wrote:
> On Fri, Dec 3, 2021 at 4:15 AM Rob Landley <rob at landley.net
> <mailto:rob at landley.net>> wrote:
> 
>     On 12/1/21 5:23 PM, enh via Toybox wrote:
>     > ---
>     >  toys/pending/strace.c | 2 +-
>     >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
>     Applied, but the real problem is that different targets have different syscalls
>     in their headers, and the C() macros build break if a given syscall isn't there.
> 
> yeah, i'd already fixed this (because rpi400 is arm32) but you sent your
> refactoring before i sent you that, and i haven't rebased yet. i'll try to do
> that this weekend.

I noticed the build break on arch/sh but hadn't tried to whack-a-mole fix it, I
jumped straight to a systemic approach. If the breakage isn't deep and we don't
care about commplete coverage...

>     I posted about the start of automating syscall/ioctl harvesting from headers,
>     and have a TODO item to see if the kernel's trick can be adapted here:
> 
>     #define __ARG_PLACEHOLDER_1 0,
>     #define __take_second_arg(__ignored, val, ...) val
>     #define __is_defined(x)                 ___is_defined(x)
>     #define ___is_defined(val)              ____is_defined(__ARG_PLACEHOLDER_##val)
>     #define ____is_defined(arg1_or_junk)    __take_second_arg(arg1_or_junk 1, 0)
>     #define IS_BUILTIN(option) __is_defined(option)
> 
>     Unfortunately getting it to resolve to itself when #defined and nothing when not
>     defined (basically a generic macro version if #ifdef) is tricksy, and so far
>     hitting the headers with sed to make something to #include at build time looks
>     like a more promising approach...
> 
> i don't think there are as many #ifdefs as you think... even mips wasn't *that*
> bad. (and the interesting parts are mostly in the crap like dealing with 64-bit
> arguments split over multiple registers and the like, which requires code
> differences anyway.)

I saw but had not yet opened that can of worms. The man page talks about the
need for aligned register pairs for certain architectures passing 64 bit values
in 32 bit registers, but only in certain legacy system calls...

> of course, i'm biased in the opposite direction: build system stuff is a bigger
> cost to me personally [who has to maintain a parallel one] than #ifdefs in a .c
> file.

Someday I'd still like to understand why "make android_defconfig" the same as
the bsd and macos ones isn't an acceptable approach, but it's on the todo list
after replacing the kconfig directory with a new implementation...

> i'm even kind of conflicted on the idea of doing an _initial_ "import" harvest
> of the ioctls... i know "real" strace does,

I haven't looked at what the other implementation does in years. (I generally
don't, for license reasons.)

> but i've always personally found the
> `sys_1234(x0,x1,x2,x3,x4,x5,x6)` format for unsupported syscalls more honest
> than the `ioctl(fd, SOME_I2C_THING, hex address)` format. it's kind of
> half-useful i guess,

Seems like step 1 of parsing by hand would be to look up the mnemonic for the
syscall or ioctl? (There's always the possibility of running an old strace
binary on a newer kernel where you have to fall back to the number...)

> but either way, i'm probably going to be working on strace
> before i continue what i was doing... but, yeah, i guess the steady state of
> "real" strace is that it knows all the syscalls and at least knows all the
> _names_ of the ioctls, and we're a long way from either. so a harvest probably
> makes sense, and should probably include both syscalls and ioctls?

Getting the number->name mappings is a reasonably straightforward grep. Getting
the function arguments for the syscalls is less straightforward but still
automateable. Turning the argument data types into something that can be
decomposed into primitive types for output is a flaming pain but possible, and
then magic flag macros ala O_RDWR pretty much have to be done by hand one at a time.

> one other issue i'd see with trying to do this at build time would be
> distinguishing personalities on a multiarch system... i'm struggling a bit to
> come up with a concrete example, but i think x86-64 doesn't have socketcall(2)
> but x86 does, and you'd either need to make that distinction in your tool or
> include #ifdefs anyway.

I'd prefer having separate strace-i386 and strace-x86_64 binaries. I'm not sure
how this works in the $PATH and maybe there would be some handoff plumbing when
the 64 bit one attaches to a 32 bit process, but trying to get one binary to
handle multiple formats brings us out of the realm of #ifdefs.

> or is that what you meant? a generated file of #ifdefs so they're still there,
> but you don't have to look at them? yeah, i can tell you that works (at least
> for arm/arm64/x86/x86-64) because bionic has a python script that does basically
> that for a different reason :-)

I was thinking more #include "strace-arm32.h" but that's just a different
interface to the same thing...

So far I've been trying to come up with a feasible approach to harvest the data,
not finalizing what the result should look like. And I've only had a couple
short cracks at it, I was mostly trying to get a release out. :)

> ...but i don't think that really helps you here because you still need the
> #ifdef for the *decoder*, right? i mean, mmap vs mmap2 is just a sad fact of
> life, and any strace is going to have to have code for both, but only use one on
> any given architecture?

I haven't tried to optimize that out.

> and like i said, the number of instances really isn't that large. at least not
> the ones i've seen come up in practice in bionic. my plan was basically "let's
> just do it, and worry about being clever with code generation or whatever when
> we can see the whole problem"...

*shrug* It's still in pending, I'm happy to stay out of your way if you've still
got work to do on it. I just couldn't use it on my turtle board yet, so took a
quick poke at it...

Rob