From patchwork Tue Feb 21 21:19:28 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sergey Bugaev X-Patchwork-Id: 1745936 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=SvzpiDmI; 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 4PLscs0Jrtz240n for ; Wed, 22 Feb 2023 08:19:56 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 63CCB385843D for ; Tue, 21 Feb 2023 21:19:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 63CCB385843D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1677014394; bh=iQAX7uVjihYKsYGMAgICVaDANUNzbhsUG4U8aanAR+U=; h=To:Cc:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=SvzpiDmISvGYMLKymSYGjJLnur+avb476R8lR3jmnGriLeQLrRU7WRQYbzP1d8Muu pQMugSEw85emUhL/WScP2WIOiqCNofaaomTD3Y3jm042CBwyGGKQMd+PQemE7f5gDW MjBl8HbeJQTp4N1pDvRhBzhX+4RBYfxkk1QbzL7g= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) by sourceware.org (Postfix) with ESMTPS id 094CE3858D35 for ; Tue, 21 Feb 2023 21:19:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 094CE3858D35 Received: by mail-lf1-x132.google.com with SMTP id bp25so7610157lfb.0 for ; Tue, 21 Feb 2023 13:19:37 -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=iQAX7uVjihYKsYGMAgICVaDANUNzbhsUG4U8aanAR+U=; b=X33SZrlWg6g684yYUzRN35g+o6T0h3PmxTGfKKE821vvBdB3gDD67XikHP1fZBElfz LMBjx+2htE83zX5ZtInnP3Uh+NHdtVx6r7iOsvjLquSSTXvg6WCNSLiIIR1J0Ps3qHnr PdgPC88jmDenr9lLMHkvtnswqn+SYgFzuC/AWTI6rmfIzIzOYoexDWyqA+/S8J9e1py6 loDqPjqvzsBsZ39y2/IcehEJwvdGPWBrugk4br4gzJQ+1DdZn8pXhzAmOp7t7uTkjCKU TXv7Gb3GVCngrhkoFP45e0z/4+2m09PEomxYI69GDnox8KtDyLgcCoFuJazuEhI7Tar1 x7XQ== X-Gm-Message-State: AO0yUKVEmN+oAs91HuXKRwIgOsj6NKIISXYgSu8zN5/H0Mkq1VnSOF0f JYG/3vBW07Ni2o8aSYLp9wU= X-Google-Smtp-Source: AK7set8pZCxQ/yUtqTc8coszSJ5ihbgFH+QanmssjKItOebASm6fA1jFHQ8R/lDjS0z7FibeLdH0vQ== X-Received: by 2002:ac2:5598:0:b0:4db:6a0f:176d with SMTP id v24-20020ac25598000000b004db6a0f176dmr2073066lfg.35.1677014376341; Tue, 21 Feb 2023 13:19:36 -0800 (PST) Received: from surface-pro-6.. ([2a00:1370:818c:4a57:d7b6:7913:7a86:3102]) by smtp.gmail.com with ESMTPSA id m17-20020a195211000000b00498f77cfa63sm1949097lfb.280.2023.02.21.13.19.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Feb 2023 13:19:35 -0800 (PST) To: bug-hurd@gnu.org, libc-alpha@sourceware.org Cc: =?utf-8?q?Fl=C3=A1vio_Cruz?= , Noah Goldstein , Samuel Thibault , Sergey Bugaev Subject: [PATCH v2 0/4] More x86_64-gnu glibc work Date: Wed, 22 Feb 2023 00:19:28 +0300 Message-Id: <20230221211932.296459-1-bugaevc@gmail.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 X-Spam-Status: No, score=-3.9 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" Changes compared to v1: * Drop patches that have been pushed * Address the review comments (hopefully...) * Some more effort towards splitting changes into commits properly, and not like last time * Rewrite/simplify the heck of init-first.c I *think* I understood enough about how init-first.c worked to change it with some confidence, rather than just trying to replicate what the i386 version was doing, but for x86_64. I was able to get the much simplified i386 version to work -- there no longer are any return address rewriting tricks, and only a single weird jump out of a call stack in the !SHARED config. init & init1 are unified into one function / code path, as are doinit and doinit1. call_init is gone. There are no longer any varargs, nor assumptions that function args are passed on the stack -- everything is dealt with through a pointer. Overall, I think this version is much cleaner. I've tried to write some comments about how _hurd_stack_setup () works. There's really not much code to it, but it is tricky, so better have it documented. In my testing, both SHARED and !SHARED versions still work (on i386). Early boot !SHARED seems to work too -- specifically, I replaced the stock /hurd/ext2fs.static with the one I cross-built with this version of glibc in the boot script, and it seemed to find its arguments just fine (though the system did not actually fully boot up, but that was likely for some unrealted reason...). So please don't trust my (brief and unreliable) testing, and do your own. As for x86_64, yes, I have verified that on x86_64-pc-linux-gnu argc/argv/env arrive on-stack just like the code in _hurd_stack_setup () expects them to. I still don't understand why __LIBC_NO_TLS () is supposed to return 0 when we have the early TLS configured, but this seems to be what the i386 version does. Note: this (TLS) still depends on the gnumach patch adding i386_fsgs_base_state. If the API is alright, can we push it without an implementation, so that userland code (glibc) can be built against it? Note: the other still unpushed patches I'm carrying locally are "htl: Make pthread_mutex_t pointer-aligned" and the mach-machine part of "mach: Look for mach_i386.defs on x86_64 too". You may need to apply them to actually build any of this on x86_64. Sergey Bugaev (4): hurd: Simplify init-first.c further hurd: Generalize init-first.c to support x86_64 hurd: Implement TLS for x86_64 htl: Add pthreadtypes-arch.h for x86_64 sysdeps/mach/hurd/dl-sysdep.c | 5 +- sysdeps/mach/hurd/i386/dl-machine.h | 7 - sysdeps/mach/hurd/{i386 => x86}/init-first.c | 220 ++++++++----------- sysdeps/mach/hurd/x86_64/tls.h | 215 ++++++++++++++++++ sysdeps/x86_64/htl/bits/pthreadtypes-arch.h | 36 +++ 5 files changed, 345 insertions(+), 138 deletions(-) delete mode 100644 sysdeps/mach/hurd/i386/dl-machine.h rename sysdeps/mach/hurd/{i386 => x86}/init-first.c (67%) create mode 100644 sysdeps/mach/hurd/x86_64/tls.h create mode 100644 sysdeps/x86_64/htl/bits/pthreadtypes-arch.h