From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id eZbdJ6cPkWI0uAgAWB0awg (envelope-from ) for ; Fri, 27 May 2022 13:51:35 -0400 Received: by simark.ca (Postfix, from userid 112) id 9A2D91E221; Fri, 27 May 2022 13:51:35 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI, NICE_REPLY_A,RDNS_DYNAMIC autolearn=ham autolearn_force=no version=3.4.6 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 (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id D4A751E00D for ; Fri, 27 May 2022 13:51:34 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8E2A838293D8 for ; Fri, 27 May 2022 17:51:34 +0000 (GMT) Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by sourceware.org (Postfix) with ESMTPS id 9D8283865C2A for ; Fri, 27 May 2022 17:51:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9D8283865C2A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f44.google.com with SMTP id j25so6770534wrb.6 for ; Fri, 27 May 2022 10:51:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=olQHVQTgKbj4EgcEqHJROiTeFTtFS8bWk3gADFDTyLM=; b=e9I/fDy/SwoItUwdTGzdJAsFrH4e3WAlDOc4Qr29UzCXk0XbHF5Db3yDWnYjkWSlZu OT6UR+Prvb8kEcEk+YMqTxNreig3+nyaJShMoTQ0cKbnW0BJM00YJ8ZReCd4vsuv2s1h V5cedaOQE080h9ALN4BwgjTrMQho4NmyJeH0F7CMT9Ul1f8b8e21RoB+kT2q//KKL1Tk rKuzzzz04646wdc6kx6oUfploBZiNu7/HlDngnRsw96OIMJas1h9K2RzGdgB0y9wlNFp 2z1wWQdXdbMpC8vHPWNQ8Ug8RaPTcdTgDbX4XtFXZZoJ8chwQSMhBKfPNiwZ6kpK6/+V FIlA== X-Gm-Message-State: AOAM533aNrf3ZPoqarbLEvJM9c3+AlhcjA/r0FszQBPY62aswq1DC/qV 2pZ+E2a3Yyu4O9M3pUp/1/n25HhqCLk= X-Google-Smtp-Source: ABdhPJy26+h5C5ydLHs+JrvSl/yuIFUFHNY7WHnyngWLltmwf8WdLix8Xjt3XCqdokaVNckhjc0Lhg== X-Received: by 2002:adf:e94c:0:b0:210:56d:539b with SMTP id m12-20020adfe94c000000b00210056d539bmr9010370wrn.37.1653673881636; Fri, 27 May 2022 10:51:21 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id n15-20020a5d588f000000b0020c5253d927sm2263883wrf.115.2022.05.27.10.51.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 May 2022 10:51:20 -0700 (PDT) Message-ID: <02a46873-35dc-0d9c-1890-292b807d9484@palves.net> Date: Fri, 27 May 2022 18:51:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH v4] gdb/manual: Introduce location specs Content-Language: en-US To: Eli Zaretskii References: <20220526194250.2310460-1-pedro@palves.net> <8335gvnjrw.fsf@gnu.org> <956e1fbd-5f03-c021-c390-82e1cf3493b5@palves.net> <83wne7m0ri.fsf@gnu.org> <2bc9b5c9-879a-2848-16f4-6cfd796563a8@palves.net> <83sfounaqw.fsf@gnu.org> From: Pedro Alves In-Reply-To: <83sfounaqw.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 2022-05-27 18:31, Eli Zaretskii wrote: >> Date: Fri, 27 May 2022 18:11:04 +0100 >> Cc: gdb-patches@sourceware.org >> From: Pedro Alves >> >>> . absolute file name of the source >>> . line number in the source file >>> . fully-qualified and prototyped function >>> . address >>> . inferior number >> >> Yes. Well, except "absolute" in the file name. The file names in the >> debug info aren't always absolute, they can be something like ../a/b/c/foo.c, >> and we may not be able to find the source file in the filesystem, so the >> path the debug info tells us is all we get. > > Then the directory should also be part of the attributes, no? I thought that in GNU terminology, "file name" already included the directory? ISTR you saying that we shouldn't use "path" to describe directories sometime ago, for example. Maybe I'm misremembering it. The text I wrote in v4 purposely says "the source file the line belongs to" which avoids going into that detail. > >>>> I am not sure what you >>>> mean by "100% identical". A spec can never the identical to the actual >>>> thing, the same way a cake recipe can never be identical to a cake, for >>>> they are things of different nature. It can only be that the actual >>>> thing complies with or follows the spec. >>> >>> I thought you just explained above that, when there's only one >>> inferior, the user can give a location spec which will resolve to a >>> code location that has exactly the same attributes as the spec? IOW, >>> in this case the "resolution" of the spec produces a "thing" that to >>> the user looks exactly the same as the input spec? >> >> When you specify a function name, you can't specify an address >> at the same time, for example. There's no format that allows that. >> So if you specify a function, you end up with code location that has >> an address, but you didn't specify the address. Conversely, when you >> specify an address, gdb finds the source/line for the address if available, >> as well as the function. > > That's understood, and it not important for what I have in mind. The > important point is that the user can potentially specify every > attribute of a code location, even if some combinations cannot be > used. I guess I don't know how that fits your idea of "100% identical" then. > >> And then GDB knows more about the code locations than that set of attributes, >> of course. GDB knows the architecture of the instruction the location points >> at, for example. > > Is that exposed to the user somewhere? I'm only interested in what is > shown to the user and/or what has user-level consequences. Internal > attributes that the user doesn't have to know about are out of scope > of this issue. I guess not. I don't really understand what you're after, so I don't know what to comment further. I sounds like you are trying to say that a location spec can be exactly the same as a code location sometimes. While in my view, the found code locations will always have the attributes that match what the user specified, otherwise the locations wouldn't have been found. And I thought that that was already clear in, or obvious from, the text I wrote, and from the specific location spec format sections.