From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 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 RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 1536A1F8C6 for ; Sat, 31 Jul 2021 06:34:44 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 26D623847806 for ; Sat, 31 Jul 2021 06:34:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 26D623847806 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1627713282; bh=QX8V18hTLdup0eDe50ByarTvELy5nfG0I7UNvixiOdo=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=msbDYcIHMS9PuV1RDu7w9YpMDUyNbFVF9o2X80KhmFLzXVrC7+O2EGh79XxlAq6MG gKNnIr+Rld6klT3tby5NlhFiyN5ovR6LmPRUsa9mrbXTqNqrZ0QGPiEHSeGPA+rsNW d8Cb/wRlpTK7SCKfig6ttPNqZCnZ4LKi/Sinw8Og= Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) by sourceware.org (Postfix) with ESMTPS id 009883857C65 for ; Sat, 31 Jul 2021 06:34:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 009883857C65 Received: by mail-yb1-xb32.google.com with SMTP id a93so1511166ybi.1 for ; Fri, 30 Jul 2021 23:34:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QX8V18hTLdup0eDe50ByarTvELy5nfG0I7UNvixiOdo=; b=RFDALU+VB3TV20x1l0dprvRxWxZonsvUkpkKhy6bEfh79XQQwMUvXAPlWg6ZhB3DOX hbCOKIMpu/vS3L8I1874h11yewzNa2TkJxbbcxrAxzFt9sMXdrWDuCSzCQHUAQH+Juo1 4echGzeYt4ZQH8TJ1zpzaShz00dgdXyLJtCGNe7Jp97xCz+bvqBrIXJE2uJpMXp0yLZl bN5HG2Ih1drVfxOWI6CgBg9Ao2mTjTvHkMeWRVH+HWPTV889NPJXfeWEM+MC1yT+ZKmn edloUOsh/maKGI2CsPPvaf/WfpSta1u/1UlrTAmwbIMb605fMICbEsIsDFtEFGJSto85 mhLw== X-Gm-Message-State: AOAM531bq3SC3btS+p4hXbVtFZ1aKX4pCe8ayn7bBJ28+bOWNnZsDb7d RuG3GCprsg8sOtFmmysCn7nUyA4OJv0Ow1HUUieTog== X-Google-Smtp-Source: ABdhPJzdCDCo/VUQLvqMKERP8pCGzbzgml/U8/SbwEgdqu0lQ2vdZXhwhvQvG+UnrR0D2jLB/S9p1p0X0gSq8MV+3L8= X-Received: by 2002:a25:c42:: with SMTP id 63mr7992361ybm.240.1627713261448; Fri, 30 Jul 2021 23:34:21 -0700 (PDT) MIME-Version: 1.0 References: <20210726035802.275992-1-maskray@google.com> <87o8akz12h.fsf@oldenburg.str.redhat.com> In-Reply-To: <87o8akz12h.fsf@oldenburg.str.redhat.com> Date: Fri, 30 Jul 2021 23:34:09 -0700 Message-ID: Subject: Re: [PATCH 0/3] Allow LLD 13.0.0 and improve compatibility with gold and clang To: Florian Weimer Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: , From: =?utf-8?q?F=C4=81ng-ru=C3=AC_S=C3=B2ng_via_Libc-alpha?= Reply-To: =?UTF-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Cc: Fangrui Song via Libc-alpha Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Fri, Jul 30, 2021 at 12:57 AM Florian Weimer wrote: > > * Fangrui Song via Libc-alpha: > > > For malloc/tst-compathooks-on, > > > > malloc/tst-compathooks-on: Symbol `__free_hook' has different size = in shared object, consider re-linking > > > > the root cause is that lld's symbol versioning is different from GNU ld= in an unusal case: > > > > __asm__ (".symver " "__free_hook" "," "__free_hook" "@" "GLIBC_2.2.= 5"); > > > > This leaves two symbols __free_hook and __free_hook@GLIBC_2.2.5. > > __free_hook is then attached a default version GLIBC_2.2.5. > > I think malloc/malloc-debug.c uses a fragile versioned symbol here. > > If the inline asm uses @@ the failure should go away. > > But we want to produce a compat symbol here. With the current version > scripts, BFD ld will not export a symbol unless it is listed in the > version script. That is, if I remove __free_hook from libc_malloc_debug > in malloc/Versions, I get an ABI check failure: > > --- ../sysdeps/unix/sysv/linux/x86_64/64/libc_malloc_debug.abilist 2= 021-07-27 16:14:51.516781791 +0200 > +++ =E2=80=A6/malloc/libc_malloc_debug.symlist 2021-07-30 09:55:09.81887= 5449 +0200 > @@ -3 +2,0 @@ GLIBC_2.16 aligned_alloc F > -GLIBC_2.2.5 __free_hook D 0x8 > > If this works with a linker, it appears to ignore =E2=80=9Clocal: *;=E2= =80=9D in version > nodes for versioned symbols. That looks like a linker bug. > > Thanks, > Florian > I have a comment on https://sourceware.org/bugzilla/show_bug.cgi?id=3D23328= #c6 How does removing __free_hook from malloc/Versions break the ABI check test= ? % cat a.s .symver __free_hook, __free_hook@GLIBC_2.2.5 .globl __free_hook __free_hook: nop % cat a.ver GLIBC_2.2.5 {}; /* should not list the non-default version __free_hook */ local { local: *; }; % cc -c a.s % ld.bfd -shared --version-script=3Da.ver a.o -o a.so % readelf -W --dyn- a.so | grep free_hook 3: 0000000000001000 0 NOTYPE GLOBAL DEFAULT 7 __free_hook@GLIBC_2.2.5 One non-default version symbol, as expected.