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:11:04 +0100	[thread overview]
Message-ID: <2bc9b5c9-879a-2848-16f4-6cfd796563a8@palves.net> (raw)
In-Reply-To: <83wne7m0ri.fsf@gnu.org>

On 2022-05-27 16:52, Eli Zaretskii wrote:
>> Date: Fri, 27 May 2022 16:04:32 +0100
>> Cc: gdb-patches@sourceware.org
>> From: Pedro Alves <pedro@palves.net>
>>
>>>   > +A concrete code location in your program is uniquely identifiable by a
>>>   > +set of logical attributes.  Typically, a line number, the source file
>>>   > +the line belongs to, the fully-qualified and prototyped function it is
>>>   > +defined in, and an instruction address.  Because each inferior has its
>>>   > +own address space, also an inferior number.
>>>
>>> The "typically" part and the overall style seem to say that this is
>>> not the exhaustive list of all the attributes of a code location, just
>>> a general idea.  Can you please present a full exhaustive list of the
>>> attributes of a code location?
>>
>> I meant to remove the "typically", and forgot it, sorry.  It is not
>> supposed to be there.
> 
> OK, so I take it the full list is:
> 
>   . 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.

> 
>>> And another question: does the process of resolving a location spec to
>>> obtain the corresponding code locations involve only filling in of the
>>> attributes that were omitted from the spec, or does it also produce
>>> attributes that can _never_ be part of the location spec?  IOW, can
>>> the user type a location spec which will yield a code location that is
>>> 100% identical to the input spec?
>>
>> Currently there's no way to explicitly specify the inferior with
>> any format of location specifications.  So if you do "b func", and you
>> have multiple inferiors, GDB will find code locations for "func" in all
>> the inferiors.  All the other attributes you can explicitly specify.
>> Not sure whether that answers your question.
> 
> I think it does, but:
> 
>>                                              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.

So you can't pass the whole set of attributes at once, some combinations can't
be specified, or are incompatible/ignored.

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.

  reply	other threads:[~2022-05-27 17:11 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 [this message]
2022-05-27 17:31         ` Eli Zaretskii
2022-05-27 17:51           ` Pedro Alves
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=2bc9b5c9-879a-2848-16f4-6cfd796563a8@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).