From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) by sourceware.org (Postfix) with ESMTPS id 6D090384BC17 for ; Wed, 17 Mar 2021 20:16:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6D090384BC17 Received: by mail-qt1-x82b.google.com with SMTP id a11so2431194qto.2 for ; Wed, 17 Mar 2021 13:16:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=F71do7DprJ+orhfM6Cxy2VmS0UOva30RW9Xw5yY9s9c=; b=fkk8W7C/ludf8U2LYJXqruDKE5RUteCESFD1kF0Hgfp7M4jmI7FydqKKbHumoBKUN0 PVu8Se5DjFj8TIp30A55eDEbrhvB9k0f63OknPDV0m6hps+D+/zpU3yQKD1nxJXs5Nsf F+ha4d+JYrrPH42Fmsid0iZ6aOIc4AUKPDe8cBwLs/l4BEj6iaFVtt+ruRyyIOEN4xH4 zL6XVKtyPwoKTaKIdqDBU8aFfVDDAZgYngZhtzPSH1yHQdOatcXghrc3y7f4Nu3I7zjt burtaLoXKRfXq9Y3PosTOHLqXp+mdZU8ChPU7aJs9YRb/5A2cLFnllS5K4b4vMa1/DxY hgsQ== X-Gm-Message-State: AOAM530LjR4nzvUqNAZrNXbdAdl4gtifnpXOpikD3NLJqi88RV1f2Yd1 2GwZQsm/o4/US0N61/KZbx1qtDtpJST46mpk X-Google-Smtp-Source: ABdhPJxziHp7z3cNQeCv0FXyZ4XclZIoYogLSgxU3ZQX2cxbS1QZCSgrrL/lzod7rHueH2/1pRIWEw== X-Received: by 2002:ac8:73c4:: with SMTP id v4mr793916qtp.208.1616012212795; Wed, 17 Mar 2021 13:16:52 -0700 (PDT) Received: from [192.168.1.4] ([177.194.48.209]) by smtp.googlemail.com with ESMTPSA id 30sm16064999qta.38.2021.03.17.13.16.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Mar 2021 13:16:52 -0700 (PDT) To: Florian Weimer , Adhemerval Zanella via Libc-alpha References: <37181fcb-03db-dec0-11bd-01009324d2c5@linaro.org> <871rcdy2ru.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Subject: Re: [PATCH v3 09/37] nptl: Move __pthread_unwind_next into libc Message-ID: <3391e1fd-44c9-9231-3289-23968b61b0a9@linaro.org> Date: Wed, 17 Mar 2021 17:16:49 -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: <871rcdy2ru.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, URIBL_BLACK autolearn=no 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: Wed, 17 Mar 2021 20:16:54 -0000 On 17/03/2021 16:54, Florian Weimer wrote: > * Adhemerval Zanella via Libc-alpha: > >> On 16/03/2021 14:29, Florian Weimer via Libc-alpha wrote: >>> It's necessary to stub out __libc_disable_asynccancel and >>> __libc_enable_asynccancel via rtld-stubbed-symbols because the new >>> direct references to the unwinder result in symbol conflicts when the >>> rtld exception handling from libc is linked in during the construction >>> of librtld.map. >> >> From where exactly these come from? The *assynccancel should not be >> generated for rtld-* objects. > > I think what happens is this: The libc.so objects that are used as a > starting point have them, so the reducer tries to link in those symbols, > and that fails with symbol conflicts. Right, but why doesn't it happen with other symbols that might be pulled as well? It not a blocker, but I am trying to understand why we are seeing this behavior with this change.