From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) by sourceware.org (Postfix) with ESMTPS id 372E43858CDB for ; Thu, 9 Mar 2023 16:18:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 372E43858CDB 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-pg1-x536.google.com with SMTP id q189so1369534pga.9 for ; Thu, 09 Mar 2023 08:18:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678378699; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=bL5D8woIt7CO4yL73CTrECTCB6Bvg3aK6hrxDWbobPs=; b=pgQd8IOQBnBIrfAUHsV9M6KNkZjzvJ4duSpTQEttGD382PQtgyV3oHheRyqa8PPIbw zGB8iDndGHikfwW6o3PAbo68Taxad2iK88jj9Q+rG+xbeLnbJDkWMB+lPzWAa/sqSItK Uvj3vVI4yMIDRgRr28xtl7I2HYDDWgTv2WOZcuRpIUnmInqjRcuDUBHVWIbX6QCB0boT ZzvccFQn/AesGAQt57TilpFzIbmaR+bQw8GsbBO4kY+9OflWMfrt01DKSgqGMyDewxiz +6c3tKNg6Oe47/Yc/ZJE5/n2Cp9mn++CmIZifixsmeRpC/w4EioygDGlRd6Fe+1wDejC KNZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678378699; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=bL5D8woIt7CO4yL73CTrECTCB6Bvg3aK6hrxDWbobPs=; b=R2t7SsA7wToyHu3EvkOC7xsrAc5skZHXnoCMBNPv39U1AEa8ocnzCwFOxbIRaeWA+i VogtVW4YD/tA013uSWe6I6o+tyT7XPoIBT9FEk8tjihXP65P0ropxpYVr84C9k2kArpo LjSWjG1w4/5jSOuD/g+D0Aajw6jNNtRJUDJT3oSHwirVSQ1/lzuqZ8++WLc+bEtIAkzP HdtN1PPGhdaNo7JuiFw6LNjekMx4l9sO4uK3zGZ43Ao73mmIQnV+6kUMFA/HpZtkwlqT G60if11zjM9u8vrENhEqCHorWUK33nLVV/bOBmZA3yNsWo4eN6MY9WcBi1CD3Q9egknR CtrA== X-Gm-Message-State: AO0yUKWNWWsz6Kao1EoH7E9Z2bDuZh5ye/7DOcb4CEWPF+J9okRctF1q jAmu4ka9n1iXomzH2lL2jwkO3WeW+XHotK/8Tmwq1zkRxKM= X-Google-Smtp-Source: AK7set8OkJYylGu97xlzIsVpxouftAOIA9Hwq3WtvhnLveQmKp+tyDtq0MALL/EIMEHkw7QV22RWnc/tpn6aLBJCrMM= X-Received: by 2002:a63:7e56:0:b0:503:8226:f872 with SMTP id o22-20020a637e56000000b005038226f872mr7929947pgn.0.1678378697247; Thu, 09 Mar 2023 08:18:17 -0800 (PST) MIME-Version: 1.0 From: Sergey Bugaev Date: Thu, 9 Mar 2023 19:18:07 +0300 Message-ID: Subject: x86_64-gnu port -- help needed To: libc-alpha@sourceware.org, Samuel Thibault Cc: bug-hurd Content-Type: multipart/alternative; boundary="0000000000000d217705f679fed6" 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,HTML_MESSAGE,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: --0000000000000d217705f679fed6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello! So continuing with the x86_64-gnu port, I wrote and tweaked some things and got it to compile further, and now I'm facing linking issues. I've been scratching my head (figuratively...) about this one for > 24 hours now, so it's only appropriate that I ask for some help. First, the error message: x86_64-gnu-gcc -nostdlib -nostartfiles -r -o elf/librtld.map.o elf/librtld.mapT.o '-Wl,-(' elf/dl-allobjs.os libc_pic.a mach/libmachuser_pic.a hurd/libhurduser_pic.a -lgcc '-Wl,-)' -Wl,-Map,elf/librtld.mapT x86_64-gnu/bin/ld: libc_pic.a(_exit.os): in function `__GI__exit': posix/../sysdeps/mach/hurd/_exit.c:50: multiple definition of `__GI__exit'; elf/dl-allobjs.os:elf/../sysdeps/mach/hurd/dl-sysdep.c:728: first defined here x86_64-gnu/bin/ld: libc_pic.a(strtoul.os): in function `__GI___strtoul_internal': stdlib/../sysdeps/wordsize-64/strtoul.c:108: multiple definition of `__GI___strtoul_internal'; elf/dl-allobjs.os:elf/../sysdeps/mach/hurd/dl-sysdep.c:713: first defined here (I've trimmed down the paths to be less unwieldy; in reality they're all absolute, e.g. /home/sergey/dev/crosshurd64/src/glibc/build/elf/librtld.map.o) My understanding is that __GI__ symbols are created by the hidden_proto/hidden_def macros from include/libc-symbols.h, and used for avoiding PLT when using glibc symbols from inside glibc itself (how it's different to the __-prefixed symbols, I have not yet figured out). There is indeed the __GI__exit strong .text symbol in both libc_pic.a(_exit.os) and elf/dl-allobjs.os: $ nm -A libc_pic.a 2>/dev/null | rg __GI__exit libc_pic.a:version.os: U __GI__exit libc_pic.a:abort.os: U __GI__exit libc_pic.a:exit.os: U __GI__exit libc_pic.a:_exit.os:0000000000000460 T __GI__exit libc_pic.a:daemon.os: U __GI__exit libc_pic.a:openchild.os: U __GI__exit libc_pic.a:forkpty.os: U __GI__exit $ nm -A elf/dl-allobjs.os | rg _exit elf/dl-allobjs.os:00000000000192b0 T __check__exit_no_hidden elf/dl-allobjs.os:00000000000192b0 W _exit elf/dl-allobjs.os:00000000000192b0 T __GI__exit elf/dl-allobjs.os: U __proc_mark_exit but this same thing is true of my i686-gnu build, which somehow works! $ nm -A libc_pic.a 2>/dev/null | rg __GI__exit libc_pic.a:version.os: U __GI__exit libc_pic.a:abort.os: U __GI__exit libc_pic.a:exit.os: U __GI__exit libc_pic.a:_exit.os:000004a0 T __GI__exit libc_pic.a:daemon.os: U __GI__exit libc_pic.a:openchild.os: U __GI__exit libc_pic.a:forkpty.os: U __GI__exit $ nm -A elf/dl-allobjs.os | rg _exit elf/dl-allobjs.os:000190a0 T __check__exit_no_hidden elf/dl-allobjs.os:000190a0 W _exit elf/dl-allobjs.os:000190a0 T __GI__exit elf/dl-allobjs.os: U __proc_mark_exit Here, it just says i686-gnu-gcc -nostdlib -nostartfiles -r -o elf/librtld.map.o elf/librtld.mapT.o '-Wl,-(' elf/dl-allobjs.os libc_pic.a mach/libmachuser_pic.a hurd/libhurduser_pic.a -lgcc '-Wl,-)' -Wl,-Map,elf/librtld.mapT i686-gnu/bin/ld: warning: elf/dl-allobjs.os: requires executable stack (because the .note.GNU-stack section is executable) (Again, I've trimmed the paths.) Questions: 1. What is this about, what's it even trying to do? If this is linking the dynamic linker (ld.so / rtld =E2=80=94 these are the same thing, right?), t= hen why does it need the dl-sysdep version if the real version is available? If this is something else, such as maybe testing that the dynamic linker and glibc proper don't have symbol conflicts, then clearly they do! 2. Why does dl-sysdep define a strong __GI__exit and not a weak one? Isn't the point to upgrade to the full version once it's available? (But would that even work, considering __GI__ function calls do not go through PLT?) 3. How come this works on i686-gnu, the duplicated symbols are clearly present there too! 4. Whatever the answer to #2 is, why doesn't it work on x86_64-gnu? Sergey --0000000000000d217705f679fed6--