From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) by sourceware.org (Postfix) with ESMTPS id 4FE7C385481F for ; Wed, 17 Mar 2021 20:44:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4FE7C385481F Received: by mail-qt1-x835.google.com with SMTP id y2so56945qtw.13 for ; Wed, 17 Mar 2021 13:44:12 -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=N/qNyNCLnTgu1H8bcE0VbLE+rv6TPBHtzevFyUDE32o=; b=LLlFru7VM7gWHCA2Qec5YCyv4i6o4bOscBEtAlBnaapkwy74PpAgHFXmkVRSu9XyY2 Hn7f+c4zjuuyKU1Hy7E8zoJ0NdP3U1sReTgTSKXmVqj+kXFlgOQIVhpKqhaIWy/M69UG 5NG4cf4ydWZzIhNDH2LDCjD6aQEGqN0SUwA7oidv8Z24SAVLv3HB2r7hGRyZrw0EIOO9 tw0MzI8K8ZNjc2ygkn4SxRJEoG2SPi5o2DusTcvbLl38VYLHikZrlGbXAZ8k3lrkQ2Ot QtQuBuM28gwmUIeptaiIGuLbKcPnWoG7DmsuFTpYxa8Q+za52tapnG1bEE9BXfUtTBag YUsQ== X-Gm-Message-State: AOAM531DG7L/Sh0BsY+VcOykUmpxrCPLZg9pl1jj+NV7BZwhjR4Ho1oN rX2Ibf6gGWuKyhMg92l3tz4VG09S5s6y0YjI X-Google-Smtp-Source: ABdhPJwivAugV5ASTDqDfOciFbQ74PFzXeQKTh2cuZtnWyaPf/hxci7dWFAv0qVx6jpH1J+uUhqOHA== X-Received: by 2002:ac8:4314:: with SMTP id z20mr845207qtm.127.1616013851070; Wed, 17 Mar 2021 13:44:11 -0700 (PDT) Received: from [192.168.1.4] ([177.194.48.209]) by smtp.googlemail.com with ESMTPSA id z5sm123300qkz.2.2021.03.17.13.44.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Mar 2021 13:44:10 -0700 (PDT) Subject: Re: [PATCH v3 09/37] nptl: Move __pthread_unwind_next into libc To: Florian Weimer Cc: Adhemerval Zanella via Libc-alpha References: <37181fcb-03db-dec0-11bd-01009324d2c5@linaro.org> <871rcdy2ru.fsf@oldenburg.str.redhat.com> <3391e1fd-44c9-9231-3289-23968b61b0a9@linaro.org> <87k0q5wmdq.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Message-ID: Date: Wed, 17 Mar 2021 17:44:08 -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: <87k0q5wmdq.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=-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:44:13 -0000 On 17/03/2021 17:33, Florian Weimer wrote: > * Adhemerval Zanella: > >> 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. > > Ah, the explanation is quite trivial: We used to have a forwarder for > __pthread_unwind, and that acted as a firewall for the rtld symbol set > discovery. Now the forwarder is gone, so the implementation of > __pthread_unwind starts to matter. > > Maybe I should stub out __pthread_unwind instead? But doing it for the > cancellation feels more natural. The cancellation stub are fine, the long term goal is to remove them anyway.