From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) by sourceware.org (Postfix) with ESMTPS id 71C353860C36 for ; Fri, 19 Mar 2021 19:34:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 71C353860C36 Received: by mail-qk1-x730.google.com with SMTP id g15so4150257qkl.4 for ; Fri, 19 Mar 2021 12:34:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uxcG6zuBU8GXfPAXpMBnKz+Qx5lNjm9BYPNTFA2h7Lc=; b=hHHF3btMNNoJWgW6LtjNFUpSPLJi30yJAztaDntgb0H8jGiHqwT6o5mR3nSywICYda tSkL1Zc9CFw4bf9ia6n7C4rNYTgmMMDQrh3pskBwByYAck1yPdUPGl6u3Py9RtFTP8Wh mp+jD66I0qwKKvCzuG3gD7WsW0J+wodj4GfuiGbCl1h8a9kHl83djlTBH0a0ltZuqpah nx8yZHs4VBJfLJ8bHPbYTToox3qq+MBqKZojz5b9PhwEszx6g0zOAKY6yu42jzw7RCi0 r33WrZhE27/SMMoJIlE4CKkA3U9kLVkmmDS3K84JXehoFuca7E5WwyngXYAl04TF65kH F+4w== X-Gm-Message-State: AOAM5333Q4C6YeZadWUcUZULtxQ1Ta4wVPhi12GvDcyVnpY8I8kKgWkk OQDsRpbLv8vCjWj28wN637GcEqnsejVdd6Mc X-Google-Smtp-Source: ABdhPJxd922UJ5VGAVwuQtpStm8Sw0oU1NWwxSzsZeZiYr+2DrCOaGxjBQztru7dYDercfvyaNGLZQ== X-Received: by 2002:a05:620a:15d4:: with SMTP id o20mr193811qkm.81.1616182456789; Fri, 19 Mar 2021 12:34:16 -0700 (PDT) Received: from [192.168.1.4] ([177.194.48.209]) by smtp.googlemail.com with ESMTPSA id 84sm5510238qkg.8.2021.03.19.12.34.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Mar 2021 12:34:16 -0700 (PDT) Subject: Re: [RFC 2/2] Fold compat_symbol_unique functionality into compat_symbol To: Florian Weimer Cc: libc-alpha@sourceware.org References: <965a0d7e0c28a5a0ce292a2b0bd39f2ba31d1a84.1616095061.git.fweimer@redhat.com> <87h7l7j6t1.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Message-ID: Date: Fri, 19 Mar 2021 16:34:13 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <87h7l7j6t1.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-13.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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-List-Received-Date: Fri, 19 Mar 2021 19:34:19 -0000 On 19/03/2021 16:13, Florian Weimer wrote: > * Adhemerval Zanella: > >>> In locale/lc-ctype.c, it seems prudent to switch to >>> compat_symbol_reference. It produces .symver directives directly, as >>> before. This side-steps the question of copy relocations, as >>> mentioned in the comment. >> >> Maybe move this change on a subsequent patch? > > It's actually necessary to avoid build failures on some m68k variants, > which duplicate the inline asm (it's in a function, so the compiler can > do that), resulting in build failures due to .equiv instead of .set. (I > switched to .equiv because some assemblers use .set for something > unrelated to symbols.) > > I can make the change before this patch, though. I think it would be better indeed. > >>> diff --git a/nptl/libpthread-compat.c b/nptl/libpthread-compat.c >>> index 820dcd6a8f..da537af76e 100644 >>> --- a/nptl/libpthread-compat.c >>> +++ b/nptl/libpthread-compat.c >>> @@ -20,10 +20,10 @@ >>> #include >>> >>> #ifdef SHARED >>> -static void >>> +void >>> attribute_compat_text_section >>> __attribute_used__ >>> -__libpthread_version_placeholder (void) >>> +__libpthread_version_placeholder_1 (void) >>> { >>> } >>> #endif >> >> I don't think there is the need to change the symbol name, on my >> test the compat_symbol can origin and alias can be the same name. > > It's necessary because the symbol version is no longer attached to the > symbol, so it's version-less and gets exported with the default > baseline, which could be something like GLIBC_2.17. I can mention this > in the commit message. I think it should be documented on compat_symbol as well about this limitation.