[PATCH] gdb/disassembly: Update to handle non-statement addresses

[Andrew Burgess]

* Pedro Alves <pedro@palves.net> [2020-07-23 19:23:40 +0100]:

> On 7/23/20 2:52 PM, Andrew Burgess wrote:
> > * Pedro Alves <pedro@palves.net> [2020-07-23 13:01:30 +0100]:
> > 
> >> On 7/23/20 9:48 AM, Andrew Burgess wrote:
> >>
> >>> FYI, I don't really consider /m "deprecated".  We don't have any plan
> >>> for how we could ever remove /m from GDB, so it's probably going to
> >>> live on forever.  That doesn't really feel like something that's
> >>> deprecated to me, just something that got known issues.
> >>
> >> Note that "help disassemble" explicitly says that it is deprecated:
> >>
> >>  With a /m modifier, source lines are included (if available).
> >>  This view is "source centric": the output is in source line order,
> >>  regardless of any optimization that is present.  Only the main source file
> >>  is displayed, not those of, e.g., any inlined functions.
> >>  This modifier hasn't proved useful in practice and is deprecated
> >>                                                        ^^^^^^^^^^
> >>  in favor of /s.
> >>
> >>  With a /s modifier, source lines are included (if available).
> >>  This differs from /m in two important respects:
> >>  - the output is still in pc address order, and
> >>  - file names and contents for all relevant source files are displayed.
> >>
> >> I've always thought that these two paragraphs are backwards -- i.e.,
> >> that we should describe /s first since it's the preferred format,
> >> and then /m should be described in comparison to /s.
> > 
> > Sure, I'm absolutely not arguing about whether it is, or is not
> > deprecated.  
> 
> And I'm just pointing out that we tell users that it is deprecated.
> 
> Don't shoot the messenger!  :-)

Sorry if I gave that impression.

We only ended up on this path because it was originally mentioned on a
patch to fix a bug in /m - "hey this command is deprecated".

At no point was I told, "hey this command is deprecated, so don't fix
bugs here".  But nor was any particular meaning attached to "hey this
command is deprecated" - so I looked for some meaning, and the only
meaning I could find (in my own mind) was " ... so why fix bugs here".

My reply was intended to mean, sure its marked deprecated, BUT, until
there's a plan to remove something, that means nothing (beyond we
might gently nudge users towards other options).

If my poor communication has given the impression that I was disputing
whether this is deprecated then I really do apologise, that was never
my intention.  I'll try harder to be clearer in future.

.... and maybe just ask when people way "hey, this command is
deprecated", rather than hunting for hidden meaning :)

Thanks for all your time,

Andrew