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=-3.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,URIBL_BLACK shortcircuit=no autolearn=no 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 81D061F4B4 for ; Tue, 22 Sep 2020 19:14:00 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1DEE5393C871; Tue, 22 Sep 2020 19:13:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1DEE5393C871 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1600802039; bh=jh9zNn+V7q9bo9E3hUVRwPeFrx4CAIM8AK3he3a9l4Q=; 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=PSE8n1e8EYzWG+gHG2rqx4t38bgB8qfaAoxTgEOVpwrPmhBarS4jz8Jo6+j3p/25H mEXckNOwy3Bm76gWgoqiYiPtVeXQQmDtFsOZ1mkgf/4sNvyliBqeIumyTvv4yVDWsf 6TaD07HiFvFEd0xfXbekAWFj/zwGeHOKEx5gg554= 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 9E226384243D for ; Tue, 22 Sep 2020 19:13:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9E226384243D Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-462-OHgNVyzwN3ScIxMIkPRXNg-1; Tue, 22 Sep 2020 15:13:52 -0400 X-MC-Unique: OHgNVyzwN3ScIxMIkPRXNg-1 Received: by mail-qv1-f71.google.com with SMTP id t4so12204258qvr.21 for ; Tue, 22 Sep 2020 12:13:52 -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=jh9zNn+V7q9bo9E3hUVRwPeFrx4CAIM8AK3he3a9l4Q=; b=Vzx6DRXCD0Hs2l0lhrNWsBet4W4wM259kdDYj2WwEs0PniBav8+CZXrmVMW4StdDMd bFUwbmJOay7aPZJshkQmiWd+pl1ie/JxQy5RWojIQrqZbDFUDkALRPLUEA26ld6ovVy+ brBC+cru+F1bh/eXC2xU7Sk3foAqDk3bSu57t4tALmrNBPxpCG9D/72yPe/bbeeZNi5w U4ucuD/xtYnOfpwhB7UDjCHVbsEVeHroa/pIc8n3D6Ws6PRLpDXGrYchJErPigYTFCtk NKwozF56eWb+Z23Ye+IEUvP7AQs2S5s6C2CuhfvPU6XFoKI3mFuxVpvScq7ANuljfYnF ghew== X-Gm-Message-State: AOAM530GW2urLAPhTgzCGNWbc1mNi+xqdLlUITvARV7IA8xlObFjqu7B GOLzdFbqL76aU+JBnpFDZAn4WWLpNf4pVnX3QaLI6k0aLN9nihvxXeSpoQmMy1T6XjlRb9Q7LrB 3CEBooEOOQ2Dct5lxQpRX X-Received: by 2002:a05:620a:15c7:: with SMTP id o7mr6415152qkm.486.1600802031561; Tue, 22 Sep 2020 12:13:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxbgdbj8NuOA0XXSJTzloW4gDsO7nG8wXQ5yx1Xlf/m5RuuPu/1rE/Wl2JR1c1Um0aaqdrgCA== X-Received: by 2002:a05:620a:15c7:: with SMTP id o7mr6415133qkm.486.1600802031276; Tue, 22 Sep 2020 12:13:51 -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 d13sm9289080qti.6.2020.09.22.12.13.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Sep 2020 12:13:49 -0700 (PDT) Subject: Re: [RFC PATCH 0/3] implement dlmopen hooks for gdb To: Andreas Schwab , Carlos O'Donell via Libc-alpha References: <20200626193228.1953-1-danielwa@cisco.com> <0f791d3a-20bc-4524-54eb-ce6df108fbff@redhat.com> <20200723184054.GD9875@zorba> <3ff42e45-b394-bf50-38c4-93baecc71497@redhat.com> <87h7rpwxke.fsf@oldenburg2.str.redhat.com> <87y2l1vhkn.fsf@oldenburg2.str.redhat.com> <87ft79ptg9.fsf@igel.home> Organization: Red Hat Message-ID: Date: Tue, 22 Sep 2020 15:13:48 -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: <87ft79ptg9.fsf@igel.home> 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 , "Jeremy Stenglein \(jstengle\)" , "xe-linux-external\(mailer list\)" Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On 9/22/20 2:17 PM, Andreas Schwab wrote: > On Sep 22 2020, Carlos O'Donell via Libc-alpha wrote: > >> Yes, absolutely, I agree completely, for it to be useful the semantics >> have to be: >> >> - If you detect a given symbol foo@GLIBC_DEBUG, then the feature is >> present and has the semantics you expect. >> >> - If you want new semantics then you need to make a foo2@GLIBC_DEBUG >> with the new semantics. >> >> What are the runtime semantics of the symbol? How do you access it? > > Isn't that the same situation as libthread_db? Yes, but coupled to libc.so, and doesn't require finding and loading another matching library. Taking that direction would mean creating a symbol in libthread_db. In this particular case the symbol would provide the address of the new structure that you could walk that contains the namespace lists (that themselves contain linkmap lists). In my opinion we should be heading towards the complete removal of libthread_db from glibc because as an interface it requires that the debugger load a library from a potentially untrusted filesystem (or container) and execute code in order to debug the process. I would rather see data-driven approaches where foo@GLIBC_DEBUG is a data symbol and exposes a structure that can be walked to gather information about the inferior. It is also difficult if not impossible for a kernel-side agent to run target code from libthread_db to resolve the result. Keeping the symbol in libc.so avoids any debugger having to locate the matching libthread_db, which is not always in the same place as the library. In summary: - Use data symbols. - Avoid needing to run code to resolve result. - Keeps interface matched and in libc.so. -- Cheers, Carlos.