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: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.4 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,RDNS_DYNAMIC,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (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 B277D1F4B4 for ; Fri, 16 Apr 2021 18:29:41 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 913A53893655; Fri, 16 Apr 2021 18:29:40 +0000 (GMT) Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) by sourceware.org (Postfix) with ESMTPS id D55B638930CB; Fri, 16 Apr 2021 18:29:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D55B638930CB Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=alves.ped@gmail.com Received: by mail-wm1-f42.google.com with SMTP id y5-20020a05600c3645b0290132b13aaa3bso2946406wmq.1; Fri, 16 Apr 2021 11:29:37 -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:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4dGdUOPErmEoOFm4FDd4Q8ydChKbIbBS8whDqKN/kGU=; b=r7bJ2z/z0ERla1a2EuaMFi0XqdapWmmh5f7SoY0QdmnOsAbQPwBOAfYah/+Aqr520y X4/CnJI/60jD3JlKNc4PqfsXPpCUiaL/UtzVqWBL6im41FWuLfS92QLcKpSnHhYzRYzn NAJ8kRfWEV9IY0TM0i1p3XVSKlvNf7HJppqBkmY1JAx3E4q6esAt6hIZhDQvf4EpTG5T qxSE+yVdzFKyzdjG8QuXy2ZHesbA+Iu6qMX1r8Luz4CqJzg5nggtI8Cp5Qy8toMb66WK n9Dzt3/sHGBPKXz0NEZgV+Urw11SRhOwUVZnFrbGLuet0N5UdyaAUPV2I8LYr2s/mhIG /OBA== X-Gm-Message-State: AOAM530/qle2izvuvX19liAkSKFSGs3yBacUSY7i13oFnPzfiddhYtPY gRSoy6Hme2EaMB6ZwSlITCs= X-Google-Smtp-Source: ABdhPJzh9Dn7d20bdD7YRUGrfpqqPOZfaavj6QXoR21HCEZUNHamxPmKycPvdwGGzZGu5DznWT/erQ== X-Received: by 2002:a05:600c:25ca:: with SMTP id 10mr9858977wml.0.1618597776813; Fri, 16 Apr 2021 11:29:36 -0700 (PDT) Received: from ?IPv6:2001:8a0:f932:6a00:6b6e:c7b6:c5a7:aac3? ([2001:8a0:f932:6a00:6b6e:c7b6:c5a7:aac3]) by smtp.gmail.com with ESMTPSA id m3sm11944957wme.40.2021.04.16.11.29.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Apr 2021 11:29:36 -0700 (PDT) Subject: Re: [PATCH glibc] nptl_db: different libpthread/ld.so load orders (bug 27744) From: Pedro Alves To: Simon Marchi , Florian Weimer References: <87sg3qnrz3.fsf@oldenburg.str.redhat.com> <73b32cc6-e201-8bac-e442-e3dddcc01e0d@polymtl.ca> <625ec5fe-bd09-860a-f617-745042b94011@redhat.com> <87fszqnqi3.fsf@oldenburg.str.redhat.com> <87blaenprw.fsf@oldenburg.str.redhat.com> <83364527-b4aa-b7cc-928b-10d20c4338a3@polymtl.ca> <78edaf4c-e2f2-8d4e-0950-98ba24367921@polymtl.ca> Message-ID: <6c1a1dfa-57cd-d4f3-235d-5d9b8df1c73b@palves.net> Date: Fri, 16 Apr 2021 19:29:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <78edaf4c-e2f2-8d4e-0950-98ba24367921@polymtl.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: , Cc: libc-alpha@sourceware.org, Kevin Buettner , gdb-patches@sourceware.org Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On 16/04/21 18:33, Simon Marchi wrote: > On 2021-04-16 1:18 p.m., Pedro Alves wrote: >> On 16/04/21 17:53, Simon Marchi wrote: >> >>> Do we need / want to fix GDB if this goes in glibc then? >> >> I think so. We may need to discuss more the "needs_setup" hack, but we >> can do that in that thread. > > In the new version I add a new inferior flag "in_initial_library_scan". > It's perhaps not ideal but the result is better than what I had in v1. > But yeah let's discuss that in that thread. > >> Given that libpthread.so is going away in the future, we should be thinking about >> addressing that as well. Does your patch fix that as side effect? > > No, I think of that as a separate problem. > >> >> If not, GDB should be keying the loading of libthread_db.so on something else. >> Making GDB try to load libthread_db in reaction to processing ld.so instead >> libthread_db.so would fix that, I think. And, it would fix this ordering problem at >> hand as well. So if we do that, maybe we don't need the other changes. > > Is it possible to have a completely static executable that doesn't use > ld.so but uses pthreads? Yes, see gdb.threads/staticthreads.exp. We handle that here, in linux-thread-db.c: /* Add ourselves to inferior_created event chain. This is needed to handle debugging statically linked programs where the new_objfile observer won't get called for libpthread. */ gdb::observers::inferior_created.attach (thread_db_inferior_created); Or do you mean, a static executable that then later on loads (or loads something that loads) libpthread.so, via dlopen? In that case, libpthread.so pulls in ld.so. > > I don't think that would work well for the "run" case, where ld-linux > arrives before libpthreads.so (and before libc.so, for when pthreads is > moved to libc.so). If we try to load libthread_db when ld-linux > appears, the symbols provided by libpthreads (or libc) won't be found. > > We would have to key the loading on when both libpthread and ld-linux > are there (or both libc and ld-linux). Yeah, I think this would work - try to load libthread_db.so when: #1 ld-linux is processed, and, #2 libpthread is processed _and_ iff ld-linux has been processed already Sounds like this should work for both run and attach, and for both current glibc and future glibc. > > Another problem with the current state (but that would be fixed with > Florian's patch I think) is that gdb has this setting "set > auto-solib-add". If off, GDB won't load the symbols of shared > libraries. _Except_ if the library if libpthread: > > https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/solib.c;h=d32b2210005fdd6a5013cfd566620d6afeae9cf6;hb=HEAD#l968 > > But it means that if auto-solib-add is off, we won't load ld.so's > symbols, and we fall back on the original problem, even if the ordering > is right. Since Florian's patch makes libthread_db only access symbols > of libpthread.so, I think that avoids this issue as well. > > But then when libpthreads is moved into libc, we'll have the problem > that libthread_db simply won't get loaded... Guess we should make GDB always read ld.so 's symbols as well, regardless of auto-solib-add.