bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH glibc 9/12] mach: Look for mach_i386.defs on x86_64 too


From: Sergey Bugaev
Subject: Re: [RFC PATCH glibc 9/12] mach: Look for mach_i386.defs on x86_64 too
Date: Sun, 12 Feb 2023 18:38:03 +0300

> >  # Translate GNU names for CPUs into the names used in Mach header files.
> > -mach-machine = $(patsubst powerpc,ppc,$(base-machine))
> > +mach-machine := $(patsubst powerpc,ppc,$(base-machine))
> > +mach-machine := $(patsubst x86_64,i386,$(mach-machine))
>
> Mmm, no, it's not actually a translation. What exactly does this fix?

The only thing the mach-machine variable is used for (as the comment
above it kind of explains) is for guessing the include guard name in
the machine-specific Mach header. They need this because, uh,

For generating mach-syscalls.mk, the build system passes '#include
<mach/syscall_sw.h>' to the compiler to be macro-expanded.
<mach/syscall_sw.h> contains lines like
kernel_trap(mach_msg_trap,-25,7), and at the very top, this:

/*
 *      The machine-dependent "syscall_sw.h" file should
 *      define a macro for
 *              kernel_trap(trap_name, trap_number, arg_count)
 *      which will expand into assembly code for the
 *      trap.
 *
 *      N.B.: When adding calls, do not put spaces in the macros.
 */
#include <mach/machine/syscall_sw.h>

So when using <mach/syscall_sw.h> normally, those kernel_trap() macros
get expanded into arch-specific assembly definitions, such as on i386:

#define kernel_trap(trap_name,trap_number,number_args) \
ENTRY(trap_name) \
        movl    $ trap_number,%eax; \
        SVC; \
        ret; \
END(trap_name)

Now back to the glibc buildsystem and the generation of
mach-syscalls.mk: the glibc buildsystem preprocesses
<mach/syscall_sw.h> (the one that contains all those kernel_trap ()
"calls") with the -D_MACH_`echo $(mach-machine) | tr a-z
A-Z`_SYSCALL_SW_H_=1 incantation. This expands to something like
-D_MACH_I386_SYSCALL_SW_H_, which "fakes" the include guard of the
<mach/machine/syscall_sw.h>! So those kernel_trap () "calls" do not
get expanded, and the glibc buildsystem then postprocesses them with a
sed invocation to strip those kernel_trap () calls:

sed -n -e 's/^kernel_trap(\(.*\),\([-0-9]*\),\([0-9]*\))$$/\1 \2 \3/p'

And *that* (faking the include guard) is what the mach-machine
variable is used for. As another comment there says, "Go kludges!!!"

Since mach/machine/syscall_sw.h is the i386 version on x86_64 (or --
is it not supposed to be?), the _MACH_I386_SYSCALL_SW_H_ guard is the
one to fake, hence setting mach-machine to i386.

P.S. As you can see, even when the patch is a simple one-line change,
there can be quite a story (and some pulled hairs) behind it :)

> To build a 64bit glibc, we'll use headers installed by a 64bit gnumach,
> i.e. into /usr/include/x86_64-gnu/

Yes, sure, I'm building with the headers from the 64-bit Mach (gnumach
master configured with --host=x86_64-gnu).

Sergey

> I have applied the rest, thanks!
>
> Samuel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]