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.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, 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 0B9D01F5AE for ; Fri, 26 Jun 2020 21:17:31 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id F3084383F860; Fri, 26 Jun 2020 21:17:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F3084383F860 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1593206250; bh=cywKC3Fle84oK8sPERLMDs3UUJFre0RKD0yUlTaV3nk=; 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=UMLWL8tGTamEkVnGInRLJE4MuIQ0d01SFEqCWKDRVxcBEz7ppS7xv4rdhNxDWpQIX wtBHnnSPm0DftmHXOEr8CoJhFoLBqTUpdlwMQBCYdXED7lhbinK/gQjXdZ3FpULA04 jFqHFUKOwyOauGucoGejZek3gz80Ay31i8pcZpTc= Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by sourceware.org (Postfix) with ESMTP id 2A0CD3870854 for ; Fri, 26 Jun 2020 21:17:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2A0CD3870854 Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-281-mxgc5LULP52GYpu_ndKrFA-1; Fri, 26 Jun 2020 17:17:20 -0400 X-MC-Unique: mxgc5LULP52GYpu_ndKrFA-1 Received: by mail-qk1-f197.google.com with SMTP id m67so6352987qkb.17 for ; Fri, 26 Jun 2020 14:17:20 -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=cywKC3Fle84oK8sPERLMDs3UUJFre0RKD0yUlTaV3nk=; b=rSSg+ZqlOYP5kVXWjYYcB51Z9lSB6qtR/3pTp3AxE1bvcqVZUoy/gdomoLTavG3ZRW +SzWupyr4+5L/CS4N3D+LyJIPa6UPZjMSoWOHSV1c3MzjJQ2z0yjzO7/lG1jAudTfeXD zzxWpJTP4oxg07nB0TavctmRLmpaiDAObvIY6WkhxAxME6jp8ZLwrfx018eAuL0keNw1 Y2K5nC9J8Z/p9iLdpogXPce/wKx50InrxlthmMAJLTwwrqS60liqFq9YQhAP6BdXo6Ci cmhbWoE4xwznwQhEOFWZDCZzQG8JKjkiZWxbQo9/a+6b9mmIjkwtfBfNem8Ek8RLOIxB ToWg== X-Gm-Message-State: AOAM531QrkMM23E5Jl1oDivuAhTWCyZxepivYcTwCCO6e/DaY3uL4F8D dJ+SDbTZ5x5Bk3x3WlpKaSJIvbcfycxn8po1HdAJ2rUj8EueDv0X8PAQLlVjFU1/NvQGP3jpCH+ W6sdUkMDT3DpKlhM2mkO1 X-Received: by 2002:a0c:fc42:: with SMTP id w2mr5068219qvp.57.1593206240127; Fri, 26 Jun 2020 14:17:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzcXw6AQ+tKYszgZnfdLjMHLs8dU70BXpbqVf62JbXFsuYxnxcuqu4Qy800u80wWSDw8Fp5RA== X-Received: by 2002:a0c:fc42:: with SMTP id w2mr5068194qvp.57.1593206239811; Fri, 26 Jun 2020 14:17:19 -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 x57sm5460456qtk.19.2020.06.26.14.17.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Jun 2020 14:17:19 -0700 (PDT) Subject: Re: [RFC PATCH 0/3] implement dlmopen hooks for gdb To: Daniel Walker , libc-alpha@sourceware.org, Florian Weimer , Pedro Alves References: <20200626193228.1953-1-danielwa@cisco.com> Organization: Red Hat Message-ID: <0f791d3a-20bc-4524-54eb-ce6df108fbff@redhat.com> Date: Fri, 26 Jun 2020 17:17:17 -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: <20200626193228.1953-1-danielwa@cisco.com> 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: Jeremy Stenglein , xe-linux-external@cisco.com Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" 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. Your proposed solution of bumping the version is unacceptable, and was last rejected by Roland McGrath. The problem is that when you bump the version the current It is easier from a backwards compatibility perspective to add a new _r_debug_dlmopen and use that instead. gdb checks for r_version != 1 and issues a warning, but keeps going: 6952 if (linux_read_memory (priv->r_debug + lmo->r_version_offset, 6953 (unsigned char *) &r_version, 6954 sizeof (r_version)) != 0 6955 || r_version != 1) ^^^^^^^^^^^^^^ 6956 { 6957 warning ("unexpected r_debug version %d", r_version); 6958 } This is bad precedent that other software might have hard checks for r_version != 1 stop operating correclty. I suggest reviewing these threads: https://sourceware.org/legacy-ml/libc-alpha/2012-11/msg00182.html https://sourceware.org/legacy-ml/libc-alpha/2012-12/msg00278.html https://sourceware.org/legacy-ml/libc-alpha/2013-01/msg00045.html An alternative suggested in 2012 was to add a new DT_* entry to point to the extended debug information e.g. DT_DEBUG_EXTENDED, and so avoid needing ld.so for lookup of _r_debug_dlmopen. Gary Benson also suggests versioning the new structure, but being very clear what a "version bump" means, in that we compatible add elements to the end after each version change. So all consumers would check _r_debug_dlmopen.r_version > 1 to know they had at least v1 elements. And for reference from Solaris: https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter6-1247.html#chapter6-15 I'd want to avoid having to run code to get at these objects, since experience has shown this is always going to cause problems. Having an entirely data-driven approach would be preferable, but locks us into an ABI that we have to be able to bump. -- Cheers, Carlos.