From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id CD62D3858284 for ; Thu, 9 Mar 2023 19:44:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CD62D3858284 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-pj1-x1032.google.com with SMTP id qa18-20020a17090b4fd200b0023750b675f5so7325884pjb.3 for ; Thu, 09 Mar 2023 11:44:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678391098; 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=O2aqlOR4CAqGlFPr9pzUP67Xie7qEtEcGuS+sGA2npg=; b=kRnb+O++NluWHMXsrMc0UIYpykt/gcNXG2WLot96ywUmT0Iu+G88zPD+/cBRXhQm6d 9qybb0gAGfYJmyAx8Z9AWn4wurKWDn8Jd7FU2yRLYhQnVN3z7MQ6oBNpNc3/Ebht5tqi G8/WYydmeSbrVb2Nr296vFsPQMueXqFkwcnRS9HoGzSQyFhNQ4v5BKts1s6K4EuruIUP 7Vh7skjRAv52OiSSyQMhLSKvQyPqFWHfhvGXDaJlfQV6YsfPf+ZwEFbsHXiBupVE4s1g SvLeJt9MM7Y+lARNRcok3alQvco3c+/oluAIZZ2LHb7kqQzsS1C10HwDK6kEBPqDhqXh A87g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678391098; 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=O2aqlOR4CAqGlFPr9pzUP67Xie7qEtEcGuS+sGA2npg=; b=xW5p+yICuj80ixlPtj8BmNduIuok1oB0Ls4M9MTHEpY2jy3UtC38XoclaXKCte9W0O 3Q78mL4ldv7KwrbWPXSaPDB8AmLOkUfAD7QXcn4J3lCBMCzQqHZnBHD2g6dGYrjgnugI CrnQSYkIlCVhFgQCzcqbAS9dwSE6E/CnbQqPiL6cgBden74mPtNl5zxML+HBQau9HAjA z0Uka0K+MMhU1bPYqCs1ZnZ+LaoJTUmVtxjbnT6eLpoDIDbyXi8+MLmhYOLiAEJ9HQ5/ t431uZL0eMbMFt8a3BADqekEOJDhJyUwMWv05Ob4MN3fKmhgrFOm0vT6VPvIcw4O+YtM gjuw== X-Gm-Message-State: AO0yUKU9zpx8B9aWNhTEJ6GMHpdlfQIkdwAPF/b5KJdONi5pjkq4jXrN 3bY6sJF2ykFqTGo7ml1SbCvdFDHRmBLY8qeVRBTTTLKnXrhIUQ== X-Google-Smtp-Source: AK7set9pmdZR9cjm1ycfZ2QMKRSVYVdiMIScQo16vv+84muxzkIEW95LmFF2+sNok1QTml2xY38D8axO2txbmsNDMRQ= X-Received: by 2002:a17:902:f7cd:b0:19a:70ed:8d22 with SMTP id h13-20020a170902f7cd00b0019a70ed8d22mr9196029plw.12.1678391097654; Thu, 09 Mar 2023 11:44:57 -0800 (PST) MIME-Version: 1.0 References: <87pm9hzvid.fsf@igel.home> In-Reply-To: <87pm9hzvid.fsf@igel.home> From: Sergey Bugaev Date: Thu, 9 Mar 2023 22:44:46 +0300 Message-ID: Subject: Re: x86_64-gnu port -- help needed To: Andreas Schwab Cc: libc-alpha@sourceware.org, Samuel Thibault , bug-hurd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.5 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: On Thu, Mar 9, 2023 at 8:26=E2=80=AFPM Andreas Schwab wrote: > Similarily, something is pulling in strtoul.os because it references a > symbol from there not defined by ../sysdeps/mach/hurd/dl-sysdep.c. > > elf/librtld.mapT should tell you where the references come from. Thank you!!! Apparently I'm misunderstanding how static linking works. I have always assumed that linking a static library works just like linking in all of its object files -- i.e. conceptually *all* object files are linked in, but the linker could optimize some away if they are not referenced by anything else. But what you're saying seems to indicate that object files are only pulled in by something referencing a symbol that they define, i.e. this is done lazily, not eagerly. In my mental model, it is fully expected that you do get all the errors like duplicate symbols and undefined symbol references from the static library, even if you don't actually use much of it, because conceptually you're linking all of it in. That's why I was so surprised to see this work for i686-gnu. That also explains why it's seemingly linking all of glibc into ld.so: it's only supposed to pull in some (hopefully very few) objects that it needs, and not all of it. And by inspecting elf/librtld.mapT, I see that the reason it's pulling _exit.os in is that ld.so needs __libc_tls_initialized in a bunch of places, and that starts a chain of dependencies that ultimately leads to _exit.os. And that also explains that difference between i686-gnu and x86_64-gnu: i686-gnu just kind of looks at %gs to figure out if TLS has been initialized, but on x86_64 I had to add __libc_tls_initialized as an explicit flag. I recall that ldsodefs.h/GL is the way to share some piece of data between ld.so and glibc proper? Should I put __libc_tls_initialized in there? How do I access GL() values from assembler, do I need to add it to some xxx-offsets.sym file? In fact, I see that there is already a sysdeps/x86_64/rtld-offsets.sym, that contains offsetof (struct rtld_global, _dl_tls_generation), so likely yes. Alternatively, what if I made a separate weak declaration of __libc_tls_initialized in dl-sysdep.c, would that work & get automatically upgraded to the "real" one once glibc is loaded? Do I understand it correctly that the downside of this approach is that this will generate another GLIBC_PRIVATE symbol reference (or will it?), and that's not nice, whereas rtld_global is one symbol multiplexing many useful pieces of data? Sergey