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.2 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 [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 910AE1F4B4 for ; Thu, 17 Sep 2020 12:52:55 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9A7D13987857; Thu, 17 Sep 2020 12:52:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9A7D13987857 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1600347174; bh=h1mmkpvMWc0E5IAsf5oLikFxcVJTjfnxEiix3WHaU5M=; 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=vEZqNbkYBHRxIq4fofB3KOL5c61VKB8tD+NVQlVF7hppWy/jOxnA0VtYfrjkECB5w vS3t73Q8lrapzHCNHHrTqZyDahLVzNevUxOOjLdCCPebEvLzZBBqMYUb2uOVsislo0 Q8oBEPIDCr66+BSdFM4mqw1PKJhkVHb4A4h2yuEU= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 171AD3857C71 for ; Thu, 17 Sep 2020 12:52:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 171AD3857C71 Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-494-aC4JjyL_OoSGyxeAKGzOkA-1; Thu, 17 Sep 2020 08:52:50 -0400 X-MC-Unique: aC4JjyL_OoSGyxeAKGzOkA-1 Received: by mail-qt1-f200.google.com with SMTP id 7so1488796qtp.18 for ; Thu, 17 Sep 2020 05:52:50 -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=h1mmkpvMWc0E5IAsf5oLikFxcVJTjfnxEiix3WHaU5M=; b=jye0tOqfVFGTMzuyWg+4WKGdonpBPv0WpXdldczrUnBbcDCIoXPgrzxaM60E54dWl4 nhxsCQmF1LQhKACUZAmGqLujc5cs/wYdn5MAeAopXlz6gMw1FBVSsfQePPgwFBKOB3HM 1RcOo+UiNmZNMgsM2TC2e5kaplOCpwfCGrgmF988YunUxMfeJrOyIzg852Q6dme8FFT0 w069tDzkra0Oj7WcNNuetZnTstSiCXYosZHu4Iu8U8A/tsX13bvYWUuDS0kSAYn/YMso DMbmvIaNTUXGN+NHqiGlddhOx5ePNURbTeZbobiPCBF0iDeATphSgGlBFI9qBSc1Fm9q kFdw== X-Gm-Message-State: AOAM533M+5vA58FR+D45jLudTmZLSO4YpV4A4+T5HmKrx/J1UjIk9S87 7NOBuJMRHlUPVjq7mh/v7mnNYsxWFznuQcNbjb7fEu5kqTIRNBv6Eh8niRV7uHeY33tgau0bdDG 7bHE4+vqjWDs4AvGU0Px1 X-Received: by 2002:ac8:4d01:: with SMTP id w1mr28833788qtv.357.1600347169717; Thu, 17 Sep 2020 05:52:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwV5OXBmZ8wK3g1UDj5J7DnfN14rrVkoShq80sSNp6ewlsA6EwWelz09hbDzyk+L+Be0Jq2ZA== X-Received: by 2002:ac8:4d01:: with SMTP id w1mr28833766qtv.357.1600347169407; Thu, 17 Sep 2020 05:52:49 -0700 (PDT) Received: from [192.168.1.16] (198-84-214-74.cpe.teksavvy.com. [198.84.214.74]) by smtp.gmail.com with ESMTPSA id s20sm20750285qkg.65.2020.09.17.05.52.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Sep 2020 05:52:48 -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> <3ff42e45-b394-bf50-38c4-93baecc71497@redhat.com> <20200916161836.GW7261@zorba> Organization: Red Hat Message-ID: <85ee3ea9-039b-a5db-a84e-224924822c79@redhat.com> Date: Thu, 17 Sep 2020 08:52:47 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200916161836.GW7261@zorba> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US 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 9/16/20 12:18 PM, Daniel Walker (danielwa) wrote: > On Thu, Jul 23, 2020 at 05:20:23PM -0400, Carlos O'Donell wrote: >> 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. >> > > > The second structure seems to work except making it available to GDB. I would > guess there are suggestions for this from you or this list. > > A couple ideas, > > 1) GDB does pointer arithmetic off the r_debug DT_DEBUG value to find the > r_debug_dlmopen structure. Add a linker script into glibc to force the two > structures arrangement in memory, or use a section tag. In gdbserver I see that it's using DT_DEBUG exclusively to find _r_debug. in gdb/solib-svr4.c: 798 /* Find DT_DEBUG. */ 799 if (scan_dyntag (DT_DEBUG, exec_bfd, &dyn_ptr, NULL) 800 || scan_dyntag_auxv (DT_DEBUG, &dyn_ptr, NULL)) 801 return dyn_ptr; 802 803 /* This may be a static executable. Look for the symbol 804 conventionally named _r_debug, as a last resort. */ 805 msymbol = lookup_minimal_symbol ("_r_debug", NULL, symfile_objfile); 806 if (msymbol.minsym != NULL) 807 return BMSYMBOL_VALUE_ADDRESS (msymbol); This code makes the most sense to me. You look for DT_DEBUG otherwise lookup _r_debug (which is _r_debug@@GLIBC_2.2.5 on x86_64). I would say that finding _r_debug_dlmopen would require lookup up the symbol, not as a last resort, but as a definition of the API. You will always have .dynsym with a definition for _r_debug_dlmopen. > 2) Add another dynamic linker entry to go along with DT_DEBUG like > DT_DEBUG_DLMOPEN. This is one way which avoids hard coding _r_debug_dlmopen and instead puts it into a DT_* tag, but requires we add a new tag. I have no strong opinion here. Having the tag avoids going through the symbol lookup, so it could have good value. In gdbserver/linux-low.cc we have get_r_debug which doesn't do anything but looking at DT_DEBUG. This would need changing to to lookup _r_debug_dlmopen in that area, or DT_DEBUG_DLMOPEN. However, looking at my i686/x86_64 system I don't see DT_DEBUG being set so I don't know how this works with gdbserver? I could have sworn we were using DT_DEBUG on x86... if we don't then we should fix that, but that's another bug. -- Cheers, Carlos.