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: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, 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 (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id F242C1F4B6 for ; Fri, 12 Jul 2019 02:32:34 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=WIRYqWJRfvZ8qhUM kpKyn4tSuMsW5JLl8iAA7KYsNT5tOcluRX+wA+lyfE/IuVTKFFkkj9U8P8zjff5J rZSsVhOIvKFkw//6S6QW+MLANeKiLc26xrFsiB1b0zMFuRgAYEVFeqPQZSfzS/aE Q/mMscSv/YUS75Bf2K/Ly6kuXYk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=OiML8KLZVYiiMthfKGHLr+ 05cjs=; b=mvjf+W0XmdD71XGO5RJi/HFyH16AUaLRA4VxvBD3usqFOQt+wDQikI +BbQ5kTvdQKtr9caIiBLHxX96H+q2WemvKlc+PnxBAsRE4NyexupGLbDdjflLwWw oN5TQDFcFaYFV3+bJNUopHwdZLmS4I+l7A9xUADJl2lto/fCIcVds= Received: (qmail 74617 invoked by alias); 12 Jul 2019 02:32:32 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 74600 invoked by uid 89); 12 Jul 2019 02:32:32 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-qk1-f195.google.com Subject: Re: CPython vs libstdc++ To: Szabolcs Nagy , Zack Weinberg , GNU C Library , "libstdc++@gcc.gnu.org" Cc: nd , Sumana Harihareswara References: <3778c39b-64f8-0615-f7d3-f7e726a6f826@arm.com> From: Carlos O'Donell Message-ID: <647538c5-4bbc-c04f-15df-659a3466d62b@redhat.com> Date: Thu, 11 Jul 2019 22:32:27 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <3778c39b-64f8-0615-f7d3-f7e726a6f826@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 7/11/19 12:50 PM, Szabolcs Nagy wrote: > they don't use dlmopen, but dlopen with RTLD_LOCAL > (well they only pass RTLD_NOW by default but that means local, > you can check/change this by sys.getdlopenflags() and sys.set...) You can have further dlopen's with RTLD_GLOBAL the promote the object to global scope and so this is a mess, and I think I've already mentioned this to upstream python developers at least once. This issue rings a bell. We've discussed python plugins and C++ in the past. The current libstdc++ is not designed to be loaded into the process image with RTLD_LOCAL, and libstdc++ uses dl_iterate_phdr() to look for loaded objects and use them during unwinding, and this is going to use the binaries object scope, not the local scope created by RTLD_LOCAL. My opinion is that if you want to use C++ with python plugins, then the python interpreter needs to be linked against one libstdc++ and then all plugins can use C/C++ for bindings, but I don't know if that would fly. >> me, because I do know that both g++-compiled C++ in general, and >> critical bits of libstdc++ in particular (e.g. the exception unwinder) >> rely on certain data objects being unique within the entire address >> space (process). >> >> On the hypothesis that the problem is caused by two copies of >> libstdc++.so and/or libgcc_s.so being loaded into a single address >> space, which cannot reasonably be made to work, even if they're the >> exact same version: we need some way of loading a shared object such >> that only one copy will be loaded, and reused for each ELF namespace >> that needs it. As far as I can tell, this is currently not possible. >> Ideally the trigger for this behavior would be an annotation on each >> shared object that needs it, rather than requiring all programs that >> use ELF namespaces to be aware of the issue; however, we might _also_ >> want a way for a program that uses ELF namespaces to request this >> behavior, in case it's trying to support old libraries that don't have >> the annotation even though they ought to. > > there is known conflict between RTLD_LOCAL and c++ odr requirement > for 'vague linkage' objects, the gnu toolchain solution using > STB_GNU_UNIQUE binding may have issues (and that can be turned > off in gcc/gold so we would need to know what toolchain were used > for those python modules) Correct, RTLD_LOCAL is a thing that doesn't make sense for C++, and so the use of STB_GNU_UNIQUE is to promote such symbols to global scope. You have to understand that for C++ some things will violate your expectations of isolation. You really need to use dlmopen here, and that has lots of bugs too because we only implement what is barely required for LD_AUDIT. Though we have RFC patches to make it better. > it's also possible that some modules were built with -static-libstdc++ > you will have to dig further. That would be a possibility, and I'm not sure what we support there. If the two plugins didn't pass relevant objects, then it might work, but again I don't know how the unwinder works with -static-libstdc++ in effect. -- Cheers, Carlos.