From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) by sourceware.org (Postfix) with ESMTPS id DC175385772C for ; Sat, 15 Apr 2023 07:34:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DC175385772C 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-oi1-x22e.google.com with SMTP id z16so13228716oib.9 for ; Sat, 15 Apr 2023 00:34:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681544098; x=1684136098; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=9H7EEQYJBoXS0GgtB4k3Y7RhQIiuueYGtCc9yyQXyo4=; b=REvx7mBxu3RTrz4U56/UsyiiCeo6EDiu1oxKTbZNgFMuXllXhYbmV2xK6jjeuxGO1F 5VMv/5tjm+jdusRHXAFE6WOc7iwvX2p9zzQ5gCW4WT/HCEOQ5N1j1Nq31VAQZyqFIcSr B7BqPxSRKOdRcwpIyM1aASNBuybWe7GIDLIAoDMJrBNqD6mhLt/Zj8NTffToB6UkfXLg TPRdtmRSW46737tIdERE1gLsYGL8g59pLlEWoyJjrp5PnJJ9dag5BbIKdwoHFB/eKkfy jgNTGzNZe2pewcMA3dHZs4WRox3a8xm/2BkFrDdlW+PKcALL9tWGWM8gHZ2B5yAb6h3o AOiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681544098; x=1684136098; h=content-transfer-encoding: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=9H7EEQYJBoXS0GgtB4k3Y7RhQIiuueYGtCc9yyQXyo4=; b=KPRBMwUI/yFRtQtfGl3cRMgLJT4zwH8kS+Q5i2wNWec4zWRQO8R7BRpK2GEUPaQLHQ OHQbzJ9wgKACygqqavbqwEUO4+aOA5sGB09JlXUZM6htXU8kFALHJTJ8j707kDnCQnsW TzMdF/Hvv/ioQ45Gx69g5e1N3rCyYFUdwCvfkn633Yl0XazL5QZGBVCYatpHJWufglx8 CEsRHuvBxX3GpvXxTA4p22fDVkZCk82qW4RvNQtOm5DV+ZmV/8W75gOrk4zqD1S6Em72 G0Fu7zvBv/S3Xt0dSsoZjSppylnj89u2FJDeeWxeyQwVBk00oUyLeGjwFlwweERtF0RZ x5HA== X-Gm-Message-State: AAQBX9fbrjymQZ/f0scFMMGxNLkPUUtqhcZLlzebkqP0mHG11+KwufXJ bY7gY9SOkZNKFFu+wwpVIaXCp3z0Pgl+gGlyLf8juLstfGS77w== X-Google-Smtp-Source: AKy350bKf5RvMHkjsBGQaJoBdz12h8agOEyVeSJS38ptOYV4w4UATMGMzDZQeb75WsHKf55xfTBQSUk+sCjmo30Rl/g= X-Received: by 2002:a05:6808:288:b0:38b:2f3f:c613 with SMTP id z8-20020a056808028800b0038b2f3fc613mr2190250oic.4.1681544098064; Sat, 15 Apr 2023 00:34:58 -0700 (PDT) MIME-Version: 1.0 References: <20230411201845.oias7lryrvm3cck7@begin> <20230413115812.267158-1-bugaevc@gmail.com> <20230414173332.afm47w6clabzklex@begin> <20230415064546.zkrmdqcrvbczm3to@begin> In-Reply-To: <20230415064546.zkrmdqcrvbczm3to@begin> From: Sergey Bugaev Date: Sat, 15 Apr 2023 10:34:46 +0300 Message-ID: Subject: Re: [RFC PATCH glibc v2 26/34] hurd: Remove __hurd_local_reply_port To: Samuel Thibault Cc: libc-alpha@sourceware.org, bug-hurd@gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.0 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,URIBL_BLACK autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Sat, Apr 15, 2023 at 9:45=E2=80=AFAM Samuel Thibault wrote: > Sergey Bugaev, le ven. 14 avril 2023 23:29:51 +0300, a ecrit: > > By the way: that __mig_dealloc_reply_port () inside > > _dl_sysdep_start_cleanup () is not doing what the author of that code > > wanted it to do. It deallocates the current reply port, but while > > doing that, it creates a fresh one in its place. > > You mean with the __mach_port_deallocate calls? Heh, well those actually too, but I didn't even think of that. We can't deallocate the reply port before the task, but we can't do it the other way around either -- fun! What I meant was __mig_dealloc_reply_port itself ends up creating a new port for the __mach_port_mod_refs RPC. Which is fine: the semantic of __mig_dealloc_reply_port is "the current reply port (also passed as an argument) might be broken, do something about it". If you really want to deallocate and reset the current reply port, you need to do the dance like sigreturn does: mach_port_t reply_port =3D THREAD_GETMEM (THREAD_SELF, reply_port); THREAD_SETMEM (THREAD_SELF, MACH_PORT_DEAD); (void) __mach_port_mod_refs (... reply_port ...); THREAD_SETMEM (THREAD_SELF, MACH_PORT_NULL); > > It would be nice to not deallocate __mach_{task,host}_self_ too, and > > instead migrate them into the new libc.so slots. > > That'd need different variables names, but that should be doable easily > by redirecting __mach_task_self in mach_init.h dependening on building > ld.so. I think we could look the symbols up in libc.so explicitly, like it's done for malloc in __rtld_malloc_init_real. But we could also do __rtld_mach_task_self_ + weak __mach_task_self_ as you're saying. > > Besides, are we 100% sure that after initially entering libc.so, ld.so > > will never do any Mach things (RPCs) anymore? > > AIUI all the OS-dependent things that ld.so calls comes from > dl-sysdep.c, so as long as all these are weak functions, we're safe. But how can we be sure of this? In fact, this is demonstrably false. elf/dl-profile.c calls __profil, which pulls sysdeps/mach/hurd/profil.c into rtld, and various other crap (threading...) along with it. Yes, I still can't get over the fact that rtld is implicitly pulling out object files from libc. Even if there's no explicit #include in rtld.c, it can still reference things that have system-specific implementations. And who knows how much of the libc proper this pulls in! Well, you can't know unless you review elf/librtld.os.map. Maybe there should be a build step that checks that nothing unexpected gets pulled in, and that nothing system-dependent is ever accessed other than through dl-sysdep. Think of it this way: the compiler can always decide to insert calls to memcpy even when there are none in the source code (unless we build with -ffreestanding, which we don't), and memcpy may have a system-specific implementation (think vm_copy / PAGE_COPY_THRESHOLD). So we cannot even verify this based on any analysis of the source code, we need this to be a post-compilation build step. Sergey