From patchwork Sun Feb 12 11:10:31 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sergey Bugaev X-Patchwork-Id: 1741011 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=sourceware.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=sourceware.org; envelope-from=libc-alpha-bounces+incoming=patchwork.ozlabs.org@sourceware.org; receiver=) Authentication-Results: legolas.ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=g6HmEreW; dkim-atps=neutral Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4PF4Y23qNhz23hX for ; Sun, 12 Feb 2023 22:11:34 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 58C9F385B50C for ; Sun, 12 Feb 2023 11:11:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 58C9F385B50C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1676200290; bh=JXMglbjcgxA4HSPrQSS232VE3T96KwWqogTytU6xbAs=; h=To:Cc:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=g6HmEreWMPzt4hz76U/RWmab/zu9OXBQzy4bPxTTDnwJIAV0zTiTNX8XiNauArtqo 2xnTshYqH7LXEwWPa866emcE3deYS2KhOJ2ZFVJ2kCIxyO1qyzy6YMVCR4Do5EvR6o ekzmkYdBDP/LjIZE/Y+4IR1/QesfRd8eAk5VaAEU= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) by sourceware.org (Postfix) with ESMTPS id 5B0563858D1E for ; Sun, 12 Feb 2023 11:11:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5B0563858D1E Received: by mail-ed1-x52b.google.com with SMTP id w3so2426633edc.2 for ; Sun, 12 Feb 2023 03:11:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JXMglbjcgxA4HSPrQSS232VE3T96KwWqogTytU6xbAs=; b=vWS3l41gtrqLb+/52pVGxB+JHEGwddWrCOUEqAherW9z5GFMVJd0wDrGTjqpNZO00I rwPITEUNF3zQFMa93aSuMM1rOBOv6aRHitp/0vzUrXlvN0CPnk82elKFlVBBNuL74Ilm rT/LvGdsNFC/2iyUM4s33BoSoSAAB2WMHyJP/kprlKrME7B8jMfYwRHlxinewyPgTUEI A+hyJsVumpXANSvTA92ACvfdIliZ2U5r/NRVPvW76breLFFDEy0NqRDpg997uzcfudIO BN+SnwsrCifuHTC4jORnOlshfD5HFWPJlPBnU4WW55spBFMrzMLmLYGz1QxMucbr0FYL +R6Q== X-Gm-Message-State: AO0yUKXoNK3bO2EcoNSlv0na0DPjqTlM0zP7tRtNmwatGnIkMao8whif txOvx5HT5MUC1zx1e1S6gjc= X-Google-Smtp-Source: AK7set/9YMPlFKxf5ksm4IWZfLaPshsBlkld0Palf1tB5DvyARyzYQdCsuA4lHtflG8ukV+N4fw0Fw== X-Received: by 2002:a50:bae9:0:b0:4ac:c576:c35b with SMTP id x96-20020a50bae9000000b004acc576c35bmr665066ede.23.1676200272037; Sun, 12 Feb 2023 03:11:12 -0800 (PST) Received: from surface-pro-6.. ([2a00:1370:818c:4a57:2186:c463:9ced:e6fe]) by smtp.gmail.com with ESMTPSA id c61-20020a509fc3000000b004acbe0b36d2sm1266910edf.6.2023.02.12.03.11.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Feb 2023 03:11:11 -0800 (PST) To: bug-hurd@gnu.org, libc-alpha@sourceware.org Cc: =?utf-8?q?Fl=C3=A1vio_Cruz?= , Sergey Bugaev Subject: [RFC PATCH 0/12] Towards glibc on x86_64-gnu Date: Sun, 12 Feb 2023 14:10:31 +0300 Message-Id: <20230212111044.610942-1-bugaevc@gmail.com> X-Mailer: git-send-email 2.39.1 MIME-Version: 1.0 X-Spam-Status: No, score=-3.6 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 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Sergey Bugaev via Libc-alpha From: Sergey Bugaev Reply-To: Sergey Bugaev Errors-To: libc-alpha-bounces+incoming=patchwork.ozlabs.org@sourceware.org Sender: "Libc-alpha" Hello! Seeing that the patches to make binutils and GCC support --target=x86_64-gnu have recently landed, I thought it would be interesting to try to configure glibc with --host=x86_64-gnu and see what breaks. To make things work at least somewhat, I've tried to put some basic directory & Implies structure in place, then fixed various 64-bit issues in generic code (these fixes should hopefully be uncontroversial!). Then I have even tried to actually write some of the missing arch-specific code for x86_64-gnu. With this patch series, I'm able to 'make install-headers' successfully. Moreover, I'm able to 'make io/subdir_objs' successfully - which builds a lot of Hurd-specific, but mostly arch-independent, routines. 'subdir_objs' in 'mach', 'hurd', and 'htl' do not succeed, but a lof of files do get built. The main missing pieces seem to be, ordered by scariness increasing: - missing x86_64 thread state definition in the kernel headers; - TLS things; - INTR_MSG_TRAP. Thread state (i.e. a struct with all the register values) should not be that hard for GNU Mach to define (unless it is defined somewhere already and I'm just not seeing it). It seems that GCC expects TLS on x86_64 to be done relative to %fs, not %gs, so that's what I attempted to do in tls.h. The main thing missing there is the ability to actually set (and read) the %fs base address of a thread. It is my understanding (but note that I have no idea what I'm talking about) that on x86_64 the segment descriptors (as in GDT/LDT) are not used for this, and instead the address can be set by writing to a MSR. Linux exposes the arch_prctl (ARCH_[GS]ET_[FG]S) syscall for this; so maybe GNU Mach could also have an explicit routine for this, perhaps like this: routine i386_set_fgs_base ( target_thread: thread_t; which: int; value: rpc_vm_address_t); We should not need a getter routine, because one can simply inspect the target thread's state (unless, again, I misunderstand things horribly). Anyway; this is an RFC. I don't expect the latter patches to actually get merged. "I have no idea what I'm doing" applies. Maybe I'm doing things horribly wrong; tell me! Note: I'm sending this as a single patch series that consists of patches for the glibc, MIG, and the Hurd repos. The repo that a patch is for is indicated in the subject line of each patch. Sergey