This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Add --gdb-format flag to dwim-print
ClosedPublic

Authored by kastiglione on Jan 10 2023, 1:19 PM.

Details

Summary

Add support for the --gdb-format/-G flag to dwim-print.

The gdb-format flag enables better compatibility with p and v, because it
allows /x and the other gdb-format specifiers.

Diff Detail

Event Timeline

kastiglione created this revision.Jan 10 2023, 1:19 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 10 2023, 1:19 PM
kastiglione requested review of this revision.Jan 10 2023, 1:19 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 10 2023, 1:19 PM
kastiglione edited the summary of this revision. (Show Details)Jan 10 2023, 6:20 PM
jingham requested changes to this revision.Jan 10 2023, 7:05 PM

I don't think this is quite right.

First off, it's a little weird that your dwim-print command only supports the gdb-format option and not the format option? In the long run, I think you need to support both. Being able to say v -fA variable but not dwim-print -fA would be wrong. But given this is early days, that can be a separate patch.

More importantly, your translation is lossy. The gdb format option supports count & size as well as format: e.g. -G 32xb. But the current code will turn that into -G x for the underlying command. So you either need to reconstitute the gdb-format string from the m_count and m_byte_size as well as m_format, or get the OptionGroupFormat to store the unparsed gdb format string and just hand that back to you.

This revision now requires changes to proceed.Jan 10 2023, 7:05 PM
jingham added inline comments.Jan 10 2023, 7:08 PM
lldb/source/Commands/CommandObjectDWIMPrint.cpp
63

Is this your long term plan? Even in a dwim print command, I will want to control the depth of structure/pointer traversal, and whether I see the raw or synthetic child version of the result, etc.

@jingham The brief answer is that decisions have been based on compatibility with the behavior of p.

  1. expression (also p) and frame variable, only support the the format part of gdb options. Neither support --count or --size and so don't support the equivalent gdb options.
  2. p takes no flags (other than the gdb-format), and dwim-print matches that behavior.

Taking the example of dwim-print -fA variable, if the user were to do the same but with an expression, they'd have to write dwim-print -fA -- expression. Will there be users who know and want the printing options you mentioned (synthetic/raw, depth, etc) but who try to use those with dwim-print instead of directly using v or e?

My expectation has been that dwim-print would (1) generally not be used directly, but be via an alias (either p or another choice) and that (2) for compatibility, the alias would be dwim-print --.

Thoughts?

kastiglione requested review of this revision.Jan 13 2023, 10:22 AM

@jingham The brief answer is that decisions have been based on compatibility with the behavior of p.

  1. expression (also p) and frame variable, only support the the format part of gdb options. Neither support --count or --size and so don't support the equivalent gdb options.
  2. p takes no flags (other than the gdb-format), and dwim-print matches that behavior.

Taking the example of dwim-print -fA variable, if the user were to do the same but with an expression, they'd have to write dwim-print -fA -- expression. Will there be users who know and want the printing options you mentioned (synthetic/raw, depth, etc) but who try to use those with dwim-print instead of directly using v or e?

My expectation has been that dwim-print would (1) generally not be used directly, but be via an alias (either p or another choice) and that (2) for compatibility, the alias would be dwim-print --.

Thoughts?

  1. I guess that sort of makes sense - since the results of expr & frame var are always typed, specifying sizes and counts doesn't make sense. Those fields only make sense for memory read. It makes the rationale for using gdb-format in the / accelerator a little less well motivated, but that's not on you...
  1. To me the analogy between p and dwim-print is not the right one. dwim-print is parallel with expr: both are full featured commands from the standpoint of configuring the output printing. p is the alias that we offer for user-convenience - it picks the defaults for the presentation. This separation is nice because then if a user has a different set of default printing expectations (they always want to print pointers one level deep or something) they can re-alias p to fit their needs, or even make two variants that serve different purposes.

So I was expecting at first we'd add a dp or something alias, that was dwim-print -- and in the fullness of time we would switch to it as the "first choice expression printer" by replacing the p -> expr -- alias with p->dwim-print --, thus getting the same convenience AND configurability we got with expr...

kastiglione edited the summary of this revision. (Show Details)

Add display options to dwim-print command

Add test with standard lldb flags

remove unnecessary header addition

Add a test for display options too (-T)

replace raise with assertTrue

jingham accepted this revision.Feb 8 2023, 6:17 PM

LGTM

This revision is now accepted and ready to land.Feb 8 2023, 6:17 PM
This revision was automatically updated to reflect the committed changes.