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-Status: No, score=-4.3 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (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 0B6DB1F5AE for ; Thu, 23 Jul 2020 21:20:32 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3305B3857C40; Thu, 23 Jul 2020 21:20:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3305B3857C40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1595539231; bh=O90a3vMbxfAlmcgs0y5B9ddyfmY1CApa5P/zNb5S6SA=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=jev2lReURAJ4HMQai4z2OCEymZp4lb/oa0aw8IvydJ1eJu21vvO52An1lMSWLZ3+s RQsCfypDhUUvdTniafZrD2+OCI6ncQ1596eosS02AjkK/PQlnM+rYzEpzAsXzTaNrf VBZZcFjZJSehOixeSENkT7CdHFi7bb01kQ55J/wA= Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by sourceware.org (Postfix) with ESMTP id D326E3858D38 for ; Thu, 23 Jul 2020 21:20:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D326E3858D38 Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-71-YjCSellwNtGkm8vnnquF8w-1; Thu, 23 Jul 2020 17:20:26 -0400 X-MC-Unique: YjCSellwNtGkm8vnnquF8w-1 Received: by mail-qt1-f197.google.com with SMTP id x6so4607868qtf.2 for ; Thu, 23 Jul 2020 14:20:26 -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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=O90a3vMbxfAlmcgs0y5B9ddyfmY1CApa5P/zNb5S6SA=; b=siEjhElkggIA42MeAQUfNgOY3BXb7XdKeArDlDZnpsK1a7e+4GVLMG1Md48KWEV5oR ecxV890LGouK1BCJgBWYNaSxkXDKVdJpMYJSPWEimOvaK+68DO6t5+8uNtFCoXD5ht9R qL7GDGbzwup705s2MwlErneyNnIDPiaML4zwP/OMRg8le9ls0N42ueuXqbzLdp21BhKM GsTAq4PIgGFQ6W+XyUuP6tcLhm1pmQB8WTO3/N4I8W3lUqNHmuu9ncq5BCoIfxNYoFdN ogGxImJvalAsk/qXFrZmcDo/8gXb/M/RDUO7kF0eoqLwFwIW06LaHuqTmxBpReOGVGeD S/hA== X-Gm-Message-State: AOAM533Q8JkFRH/NT9eWa3CuEx216YLYrcRZSGrcbF+dF1qV84FRwGtW I2RNA9FImThOHt8lAAx7ZHY2eu1aC5ZO2KNwpsGLQTSm3dYd7bzjrL819M/U815IVKwW1WgjC9b cNbTIh7Ex9U6fusrEDI8E X-Received: by 2002:a05:620a:1257:: with SMTP id a23mr2075908qkl.207.1595539226169; Thu, 23 Jul 2020 14:20:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyi91Y57Cx0J25amd9Cx+yzJE8Ppc/QRqr3Rzu+Hnk2FiaZ1mqUAhpzKZ8SjjpGTaiLonAvVw== X-Received: by 2002:a05:620a:1257:: with SMTP id a23mr2075879qkl.207.1595539225903; Thu, 23 Jul 2020 14:20:25 -0700 (PDT) Received: from [192.168.1.4] (198-84-170-103.cpe.teksavvy.com. [198.84.170.103]) by smtp.gmail.com with ESMTPSA id e23sm3678581qkl.55.2020.07.23.14.20.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Jul 2020 14:20:25 -0700 (PDT) Subject: Re: [RFC PATCH 0/3] implement dlmopen hooks for gdb To: "Daniel Walker (danielwa)" References: <20200626193228.1953-1-danielwa@cisco.com> <0f791d3a-20bc-4524-54eb-ce6df108fbff@redhat.com> <20200723184054.GD9875@zorba> Organization: Red Hat Message-ID: <3ff42e45-b394-bf50-38c4-93baecc71497@redhat.com> Date: Thu, 23 Jul 2020 17:20:23 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200723184054.GD9875@zorba> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 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: , From: Carlos O'Donell via Libc-alpha Reply-To: Carlos O'Donell Cc: Florian Weimer , Pedro Alves , "libc-alpha@sourceware.org" , "Jeremy Stenglein \(jstengle\)" , "xe-linux-external\(mailer list\)" Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On 7/23/20 2:40 PM, Daniel Walker (danielwa) wrote: > On Fri, Jun 26, 2020 at 05:17:17PM -0400, Carlos O'Donell wrote: >> On 6/26/20 3:32 PM, Daniel Walker via Libc-alpha wrote: >>> Cisco System, Inc. has a need to have dlmopen support in gdb, which >>> required glibc changes. I think it was known when glibc implemented >>> dlmopen that gdb would not work with it. >>> >>> Since 2015 Cisco has had these patches in our inventor to fix issues in >>> glibc which prevented this type of gdb usage. >>> >>> This RFC is mainly to get guidance on this implementation. We have some >>> individuals who have signed the copyright assignment for glibc, and we >>> will submit these (or different patches) formally thru those channels if >>> no one has issues with the implementation. >>> >>> Also included in this are a couple of fixes which went along with the >>> original implementation. >>> >>> Please provide any comments you might have. >>> >>> Conan C Huang (3): >>> Segfault when dlopen with RTLD_GLOBAL in dlmopened library >>> glibc: dlopen RTLD_NOLOAD optimization >>> add r_debug multiple namespaces support >>> >>> elf/dl-close.c | 7 ++++++- >>> elf/dl-debug.c | 13 ++++++++++--- >>> elf/dl-open.c | 8 +++++++- >>> elf/link.h | 4 ++++ >>> 4 files changed, 27 insertions(+), 5 deletions(-) >>> >> >> Thanks for looking at this. It is something the community would >> absolutely like to see. I'll comment quickly to provide direction. >> >> Florian Weimer, Pedro Alves, and I were talking about this as >> recently as April where we tried to agree to just adding a >> _r_debug_dlmopen with a new ABI for the debugger to use. >> > > > Here's another RFC I suppose. It's basic code I've only compile tested. It's > based on the comments, and the threads you provided. It just abstracts out the > next link into another structure. Let me know if this is in the ballpark of the > discussions. I only looked over this briefly, but I think it's on the right track. The point is to use *another* data symbol for the debugger to use to access the link maps. Then the debugger can look for that and try to use that to access a list of maps. Your next step would be to export the symbol via Versions at the current symbol node GLIBC_2.32 (soon to be GLIBC_2.33). The harder part will be the debugger changes because you have to look for _r_debug_dlmopen in preference to _r_debug, and they are different layouts, and once you find _r_debug_dlmopen you have to be able to maintain the lookup scope of the namespace you're in within the debugger. > --- > elf/dl-debug.c | 19 +++++++++++++++++-- > elf/link.h | 6 ++++++ > sysdeps/generic/ldsodefs.h | 1 + > 3 files changed, 24 insertions(+), 2 deletions(-) > > diff --git a/elf/dl-debug.c b/elf/dl-debug.c > index 4b3d3ad6ba..d0009744f8 100644 > --- a/elf/dl-debug.c > +++ b/elf/dl-debug.c > @@ -35,6 +35,7 @@ extern const int verify_link_map_members[(VERIFY_MEMBER (l_addr) > a statically-linked program there is no dynamic section for the debugger > to examine and it looks for this particular symbol name. */ > struct r_debug _r_debug; > +struct r_debug_dlmopen _r_debug_dlmopen; > > > /* Initialize _r_debug if it has not already been done. The argument is > @@ -45,11 +46,22 @@ struct r_debug * > _dl_debug_initialize (ElfW(Addr) ldbase, Lmid_t ns) > { > struct r_debug *r; > + struct r_debug_dlmopen *r_ns, *rp_ns; > > if (ns == LM_ID_BASE) > - r = &_r_debug; > + { > + r = &_r_debug; > + r_ns = &_r_debug_dlmopen; > + } > else > - r = &GL(dl_ns)[ns]._ns_debug; > + { > + r = &GL(dl_ns)[ns]._ns_debug; > + r_ns = &GL(dl_ns)[ns]._ns_debug_dlmopen; > + rp_ns = &GL(dl_ns)[ns - 1]._ns_debug_dlmopen; > + rp_ns->next = r_ns; > + if (ns - 1 == LM_ID_BASE) > + _r_debug_dlmopen.next = r_ns; > + } > > if (r->r_map == NULL || ldbase != 0) > { > @@ -58,6 +70,9 @@ _dl_debug_initialize (ElfW(Addr) ldbase, Lmid_t ns) > r->r_ldbase = ldbase ?: _r_debug.r_ldbase; > r->r_map = (void *) GL(dl_ns)[ns]._ns_loaded; > r->r_brk = (ElfW(Addr)) &_dl_debug_state; > + r_ns->r_debug = r; > + r_ns->next = NULL; > + > } > > return r; > diff --git a/elf/link.h b/elf/link.h > index 0048ad5d4d..c81945b671 100644 > --- a/elf/link.h > +++ b/elf/link.h > @@ -63,8 +63,14 @@ struct r_debug > ElfW(Addr) r_ldbase; /* Base address the linker is loaded at. */ > }; > > +struct r_debug_dlmopen > + { > + struct r_debug *r_debug; > + struct r_debug_dlmopen *next; > + }; > /* This is the instance of that structure used by the dynamic linker. */ > extern struct r_debug _r_debug; > +extern struct r_debug_dlmopen _r_debug_dlmopen; > > /* This symbol refers to the "dynamic structure" in the `.dynamic' section > of whatever module refers to `_DYNAMIC'. So, to find its own > diff --git a/sysdeps/generic/ldsodefs.h b/sysdeps/generic/ldsodefs.h > index ba114ab4b1..d9794bc7a0 100644 > --- a/sysdeps/generic/ldsodefs.h > +++ b/sysdeps/generic/ldsodefs.h > @@ -357,6 +357,7 @@ struct rtld_global > } _ns_unique_sym_table; > /* Keep track of changes to each namespace' list. */ > struct r_debug _ns_debug; > + struct r_debug_dlmopen _ns_debug_dlmopen; > } _dl_ns[DL_NNS]; > /* One higher than index of last used namespace. */ > EXTERN size_t _dl_nns; > -- Cheers, Carlos.