From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) by sourceware.org (Postfix) with ESMTPS id 2D9FF385735C for ; Fri, 27 May 2022 18:42:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2D9FF385735C 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-f51.google.com with SMTP id j25so6911035wrb.6 for ; Fri, 27 May 2022 11:42:53 -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=uv7hIPqDv6f9AEk6vscVWYODDzt9ZpkI15vmn1RCz1s=; b=69Cl/ic7TNNMYVs3A7js8+LzGJZ64WDJ9UzV9AY/NXJSkvuGGUCQgH/GvzpuLWpRCl TJJGr2DqJQ9kyvt2uoNKF/oXsMCI4BON7C5avyVVzoXV9uH+rT8uig56pHbJbYkP7dge q+bRpSvZb4BBNQTGvnaxm9RpwLWN+I/U+Ph3JxaWWcFVbBpGXVezpunkwgHklRyUgX8y rKaa1iwTAo/Ynr2QLKTFUEPTfr8oAI32K+HteEJ6SVjwjI6VCLZioqmZsFoFqC0C/+21 kFZAMZ18sCwVM3dXlEnlKqi/ez52sB0h88HgBTa9J0WXlhCMQ/T27qf6qM7ezsxaec/O ktrQ== X-Gm-Message-State: AOAM531nvVloH6PDmGZLrVpGWjlOVMSCK6RpOFlYYDIvbVhmcSgdciX+ HQII3xOcF/Mh2cd2ManMOx7x78hfaWs= X-Google-Smtp-Source: ABdhPJzI2P++vMz1dTRDGzd436fjqKtUy5q+iFowa3feiJ9dqu9eXPOfpIXO2UlCf+ITJnAJVQrD0w== X-Received: by 2002:a05:6000:16cf:b0:210:4e1:cd3 with SMTP id h15-20020a05600016cf00b0021004e10cd3mr9788798wrf.314.1653676972265; Fri, 27 May 2022 11:42:52 -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 ay5-20020a05600c1e0500b0039765a7add4sm2988091wmb.29.2022.05.27.11.42.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 May 2022 11:42:51 -0700 (PDT) Message-ID: <113bd07c-3bfe-0780-50a9-4c41c84942e9@palves.net> Date: Fri, 27 May 2022 19:42:50 +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 Cc: gdb-patches@sourceware.org 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> <02a46873-35dc-0d9c-1890-292b807d9484@palves.net> <83pmjyn8as.fsf@gnu.org> From: Pedro Alves In-Reply-To: <83pmjyn8as.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org 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: , X-List-Received-Date: Fri, 27 May 2022 18:42:55 -0000 On 2022-05-27 19:23, Eli Zaretskii wrote: >> Date: Fri, 27 May 2022 18:51:14 +0100 >> Cc: gdb-patches@sourceware.org >> From: Pedro Alves >> >>>> 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. > > A file name includes the directory, but the directory doesn't have to > be in the absolute form, as you pointed out. So the directory > relative to which the file name is specified is part of the code > location, I think, because there could be file names in a program > which have the same name, but live in different subdirectories of a > source tree. Yes. > >> The text I wrote in v4 purposely says "the source file the line belongs to" >> which avoids going into that detail. > > Something to ponder, I guess. > >>>> 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. > > I think it's important for describing what exactly happens during the > "resolution" of a location specification into code locations. > >> 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. > > Yes, but note that the last revision of your patch says "resolves > into", not "matches". Which I think is a change for the better; I'm > trying to have a more accurate idea of what that "resolution" entails. Resolution is the act of find all the actual code location that match the user input. The found locations are the resolved code locations. Here for example: +@item list @var{locspec} +Print lines centered around the line or lines that @var{locspec} +resolves to. The meaning is that the user passes some input spec to GDB, which may even not specify any line at all, like "line func", and GDB finds all the matching locations. For each resolved location, you have a resolved line, resolved source file, resolved addr, resolved function, etc. So saying "the lines that locspec resolves to" is a simpler form of saying "the lines of the locations that locspec resolves to, ignoring locations that have no line info".