From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by sourceware.org (Postfix) with ESMTPS id 273243858D1E for ; Sun, 12 Feb 2023 15:38:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 273243858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x632.google.com with SMTP id m2so11215920plg.4 for ; Sun, 12 Feb 2023 07:38:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=OMBhZTVOzPf8lHeqAfJp3SmqiJustNzQeIpclFzY0qk=; b=eFroqPnwDIe8j+hkRBahFMLCWjKgCbA0F+CoXYRlxSc0Vp5Vqhs6C01aJJdbCecYxn PXjLDSwuSBzeI8geRXoLdrQZzuKnQyuoJwE53LUSEHAuphyLJtMYxkyy7mzuvDVlJhXJ z9s433irocMgckTrPb2rbKRG0PZ9ZEeoSVIcDmT/BWIOpWulzSuPCU+71kgoMXblEdQV I7mgyLoLUtVkMXIXXV8ycg0D14cyqfFpeKmM9WXm2hoh4Eq9iu/ygHmNyMQlMetXzNBS hxONB3xYPskl4bShxAHNfjkjuW2mJZon25L8sTgx6eD0M3gqa9W9FcXRCBKM21kJ+wkj igGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OMBhZTVOzPf8lHeqAfJp3SmqiJustNzQeIpclFzY0qk=; b=yCz6TGFCjLDoz4hGD2TOg7Nw99Ky8DFoVWtrXgfF5e8KE+J/G01dyS9Q398cbIvJpp SwHCYpZpGdoPovPVpisV4adwyce2ZxaJA8137gbgbxudWvpXes3ukuv0jsoRIDdIvc3o e3Rqci7sUQEe76Euh6D45Zk1m6ieFJaskz1FgI8kGXVR4o+lS81sioRGnF5TemymWMVW aGMIIwlxxdwLF7la5dKc6ZVOeNwJbP2eHRS6r2BkKyokhSO5LGzIKKBM26lp6gi//HFc cCz0SN4SvFBGw3D3xuUkz8hOUtNblgUoz9DowAsGfctBjQoLzzD5ZtfBFuEV0eM1D7pR d15g== X-Gm-Message-State: AO0yUKWXPbLUUe2rf8HV6ohAWiQ4P88OkzzK5Nhr3J2RKnuC8BOB9LbM rIWN4Cw5V1hfovyISAIcWi110h/fwQZbOlG7TcEk1ConfBw3Kw== X-Google-Smtp-Source: AK7set+od6Deyc+j8LOi1y/WAgtIk6WHzyf5Ns9MWuNcerjzI6jRUDgJJqapOp0+ZfvCYuhd6miJPWtQyW+Znyeo/Is= X-Received: by 2002:a17:90a:6f01:b0:233:f793:8dc8 with SMTP id d1-20020a17090a6f0100b00233f7938dc8mr122790pjk.135.1676216294053; Sun, 12 Feb 2023 07:38:14 -0800 (PST) MIME-Version: 1.0 References: <20230212111044.610942-1-bugaevc@gmail.com> <20230212111044.610942-10-bugaevc@gmail.com> <20230212150710.zuzw5nqdtwvflkrj@begin> In-Reply-To: <20230212150710.zuzw5nqdtwvflkrj@begin> From: Sergey Bugaev Date: Sun, 12 Feb 2023 18:38:03 +0300 Message-ID: Subject: Re: [RFC PATCH glibc 9/12] mach: Look for mach_i386.defs on x86_64 too To: Samuel Thibault Cc: bug-hurd@gnu.org, libc-alpha@sourceware.org, =?UTF-8?B?RmzDoXZpbyBDcnV6?= Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > > # 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 ' to the compiler to be macro-expanded. 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 So when using 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 (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 ! 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