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

[Andrew Burgess]

* 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.  I guess what I'm suggesting is that without a formal
project wide definition of what "deprecated" means then it's a pretty
meaningless label to apply to something (in my opinion).

For example, in this case, we have a command that's deprecated.

Is that command going to be removed at some point?  If we do, what
about user scripts that depend on it?  This particular command is
easily available through the MI too, so there are probably frontends
that depend on this command.

Does that mean we should never fix bugs in it, and it should be
allowed to bit-rot away until eventually it's so useless everyone
agrees we can remove it?

Does it mean it must produce the exact same output, given the same
input, for all time, even if we have to jump though hoops to maintain
that output?

Or can the command continue to evolve just like non-deprecated GDB
commands?

My suspicion is that the command will never be removed unless keeping
it in GDB somehow blocks the addition of some other, more useful
command, which feels pretty unlikely in this case.

And the reality is the command continues to evolve just like any other
command.

So for me, this should never have been deprecated at all.  It's a
command, it exists, it has some known limitations which should be
documented, the alternative (/s) command should (as you suggest) be
pushed as the "preferred" approach, but until we actually have a plan
to remove this from GDB, it shouldn't be marked as deprecated.

Thanks,
Andrew