public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@palves.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v4] gdb/manual: Introduce location specs
Date: Fri, 27 May 2022 18:51:14 +0100	[thread overview]
Message-ID: <02a46873-35dc-0d9c-1890-292b807d9484@palves.net> (raw)
In-Reply-To: <83sfounaqw.fsf@gnu.org>

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 <pedro@palves.net>
>>
>>>   . 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.

  reply	other threads:[~2022-05-27 17:51 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-26 19:42 Pedro Alves
2022-05-27 14:16 ` Eli Zaretskii
2022-05-27 15:04   ` Pedro Alves
2022-05-27 15:52     ` Eli Zaretskii
2022-05-27 17:11       ` Pedro Alves
2022-05-27 17:31         ` Eli Zaretskii
2022-05-27 17:51           ` Pedro Alves [this message]
2022-05-27 18:23             ` Eli Zaretskii
2022-05-27 18:42               ` Pedro Alves
2022-05-27 18:50                 ` Pedro Alves
2022-05-27 19:00                   ` Eli Zaretskii
2022-05-27 19:30                     ` Pedro Alves
2022-05-28  7:43                       ` Eli Zaretskii
2022-05-30 14:38                         ` Pedro Alves
2022-05-27 18:55                 ` Eli Zaretskii
2022-05-27 19:05                   ` Pedro Alves
2022-05-27 19:14                     ` Eli Zaretskii
2022-05-27 19:17                       ` Pedro Alves
2022-05-27 19:34                         ` Eli Zaretskii
2022-05-27 19:38                           ` Pedro Alves
2022-05-28  7:39 ` Eli Zaretskii
2022-05-30 14:44   ` [pushed v5] " Pedro Alves
2022-05-30 16:15     ` Eli Zaretskii
2022-05-31 11:05       ` [PATCH] Improve clear command's documentation Pedro Alves
2022-05-31 12:36         ` Eli Zaretskii
2022-05-31 13:04           ` Pedro Alves
2022-05-31 13:42             ` Eli Zaretskii
2022-05-31 14:47               ` Pedro Alves
2022-05-31 16:06                 ` Eli Zaretskii
2022-05-31 11:13       ` [PATCH] Explicitly mention yet-unloaded shared libraries in location spec examples Pedro Alves
2022-05-31 11:47         ` Eli Zaretskii
2022-05-31 11:17       ` [pushed v5] gdb/manual: Introduce location specs Pedro Alves
2022-05-31 11:31       ` [PATCH] Improve break-range's documentation Pedro Alves
2022-05-31 11:55         ` Eli Zaretskii
2022-05-31 12:03           ` Pedro Alves
2022-05-31 12:09             ` Eli Zaretskii
2022-06-01 17:17     ` RTe: Location Specs (Was: [pushed v5] gdb/manual: Introduce location specs) Eli Zaretskii
2022-06-02 11:10       ` Pedro Alves
2022-06-02 11:49         ` Eli Zaretskii
2022-06-02 12:40           ` Pedro Alves
2022-06-02 12:56             ` Eli Zaretskii
2022-06-02 13:44               ` Pedro Alves
2022-06-02 16:37                 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=02a46873-35dc-0d9c-1890-292b807d9484@palves.net \
    --to=pedro@palves.net \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).