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

[enh]

On Fri, Dec 3, 2021 at 4:15 AM Rob Landley <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 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.)

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.

i'm even kind of conflicted on the idea of doing an _initial_ "import"
harvest of the ioctls... i know "real" strace does, 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, 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?

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.

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

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

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


> Rob
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20211203/d912a586/attachment-0001.htm>