This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Add setting for max depth of value object printing (NFC)
ClosedPublic

Authored by kastiglione on Apr 18 2022, 12:03 PM.

Details

Summary

This adds a setting (target.max-children-depth) that will provide a default value for the --depth flag used by expression and frame variable.

The new setting uses the same default that's currently fixed in source: UINT32_MAX.

This provides two purposes:

  1. Allowing downstream forks to provide a customized default.
  2. Allowing users to set their own default.

Following target.max-children-count, a warning is emitted when the max depth is reached. The warning lets users know which flags or settings they can customize. This warning is shown only when the limit is the default value.

rdar://87466495

Diff Detail

Event Timeline

kastiglione created this revision.Apr 18 2022, 12:03 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 18 2022, 12:03 PM
kastiglione requested review of this revision.Apr 18 2022, 12:03 PM
kastiglione edited the summary of this revision. (Show Details)Apr 20 2022, 4:27 PM
lldb/include/lldb/Interpreter/CommandInterpreter.h
499

ChildrenOmitted ? (and in general are we swapping terminology completely here because some uses have been changed some haven't)

511

For this printf the cmd_name is unused.

726

You're changing truncated to omitted elsewhere but not here. Unless there's a specific reason to keep some of them I'd go all in on "omitted" or change none of them.

(some of the function names might be baked into an API somewhere, I didn't check)

lldb/source/DataFormatters/ValueObjectPrinter.cpp
791

Help me understand here. If the max depth is the default value we tell the interpreter that we've hit max depth.

If it's not the default we don't but surely we have hit the max depth, just the max depth the user chose?

Seems like you'd want to signal the interpreter either way but clearly not because you felt the need to track if it was default. Is this because the interpreter uses ReachedMaxDepth for depths other than the one we're talking about here?

lldb/source/Interpreter/OptionGroupValueObjectDisplay.cpp
103

Should this only be set if parsing succeeds?

At least in the interactive mode I could do settings set ... <some rubbish> and it wouldn't change the value. Well, it would set it to UINT32_MAX again which doesn't seem like the user actually set something to me since we rejected their input.

lldb/source/Target/Target.cpp
4240

Given that this is a new function and the only caller provides a valid pointer, I'd make this (bool &is_default).

thanks for the review @DavidSpickett

lldb/include/lldb/Interpreter/CommandInterpreter.h
499

In the other place where I replaced "Truncate" with "Omit" it was to generalize the enum to be usable for the existing "truncate" and the new max depth cut off. Here, I felt that "truncated" could stay, as it seemed like a more specific term for this instance of omission. If other's don't see it that way then I will update this too.

511

Both warning texts do have a %s in them for the command name. I was thinking it would be better to inline the text, what do you think?

726

I missed this comment, thanks.

lldb/source/DataFormatters/ValueObjectPrinter.cpp
791

If the user has specified a max depth (either by flag or by a custom setting), then my assumption is they don't need to be reminded how to control the max depth. The warning, to my thinking, has emphasis on "here's how to adjust the limit", and not to tell you "the limit was reached". I'd like to think that seeing = { ... } in the output will be enough to say the limit was reached. A question here is: if a user has customized their setting, would they want to see the message every time? It seems lldb has a lot of one-time warnings, so now I wonder which warnings qualify for every-time.

lldb/source/Interpreter/OptionGroupValueObjectDisplay.cpp
103

good point

lldb/source/Target/Target.cpp
4240

agreed

DavidSpickett added inline comments.Apr 22 2022, 2:04 AM
lldb/include/lldb/Interpreter/CommandInterpreter.h
511

Doh, yes you're right. Without the context Phab is showing:

  const char *TruncationWarningText() {
    return "*** Some of your variables have more members than the debugger "
< "Context not available." >
           "the target.max-children-count setting.\n";
  }

But I see it in the source file.

Yes inling the strings makes sense if this is the only use.

DavidSpickett added inline comments.Apr 22 2022, 2:11 AM
lldb/include/lldb/Interpreter/CommandInterpreter.h
499

Fair enough.

You could read it either way I suppose. We have "omitted" some of the children vs we have "truncated" the list of children. Either is fine.

lldb/source/DataFormatters/ValueObjectPrinter.cpp
791

Got it. In fact you might be annoyed by the warning and go set this setting to specifically avoid it, I think it makes sense as you have it here.

Could you add a comment explaining that logic?

DavidSpickett added inline comments.Apr 22 2022, 2:12 AM
lldb/source/DataFormatters/ValueObjectPrinter.cpp
791

Tbf, I should have just read the commit msg properly "This warning is shown only when the limit is the default value." :)

A code comment is still a good addition.

aprantl added inline comments.Apr 22 2022, 10:49 AM
lldb/include/lldb/DataFormatters/DumpValueObjectOptions.h
128

Can you add a = ...; initializer here?

lldb/include/lldb/Interpreter/CommandInterpreter.h
231
/// Tristate boolean to manage children
/// elision warnings.
enum ChildrenOmissionWarningStatus 
  {
    eNoOmission = 0,       ///< None omitted.
    eUnwarnedOmission = 1, ///< Omission, but have not notified.
    eWarnedOmission = 2    ///< Omission and notified.
529

Some of the displayed variables ...
Otherwise it sounds like we're blaming the user for having such terrible variables in their code ;-)

Is fields a better generic term for `members?

723

Can you doxygenify this comment while you're there?

lldb/source/Target/Target.cpp
4240

Should it return a pair<> or a one-off struct instead?

lldb/source/Target/TargetProperties.td
76

Should we use a slightly more reasonable default value (maybe 0xff) here?

kastiglione added inline comments.Apr 22 2022, 11:37 AM
lldb/source/Target/TargetProperties.td
76

My intention was to make this change NFC, which is how I arrived at 0xFFFFFFFF, it is the current default (basically unlimited).

I am not sure who would be effected by reducing the limit, and whether it would be a desirable or undesirable effect. A change to the default could be a separate diff.

In practice, I wonder if 0xFF is any different from 0XFFFFFFFF. In other words, how often do people reach a nesting depth of 255.

aprantl added inline comments.Apr 22 2022, 12:19 PM
lldb/source/Target/TargetProperties.td
76

My intention was to make this change NFC, which is how I arrived at 0xFFFFFFFF, it is the current default (basically unlimited).

That's perfectly valid reasoning! Thanks

Updated for code review.

shafik added a subscriber: shafik.Apr 26 2022, 5:37 PM
shafik added inline comments.
lldb/include/lldb/Interpreter/CommandInterpreter.h
718

Why not use in class member initialization? It looks like they have default values. I am not sure why the rest of the values where not caught the other day when I ran clang-tidy.

lldb/source/Interpreter/OptionGroupValueObjectDisplay.cpp
180–183

My kingdom for structured bindings.

kastiglione added inline comments.Apr 27 2022, 4:55 PM
lldb/include/lldb/Interpreter/CommandInterpreter.h
718

I was following the convention within the file. What's the ideal change, initialize all in this change? Or initialize the two that I have edited?

lldb/source/Interpreter/OptionGroupValueObjectDisplay.cpp
180–183

soon, hopefully.

kastiglione added inline comments.Apr 28 2022, 9:49 AM
lldb/include/lldb/Interpreter/CommandInterpreter.h
718

I think it's best to leave these as is, and make a follow up change that uses member initialization for all of these.

Fixed: comment formatting; bool logic bug

aprantl accepted this revision.Apr 28 2022, 4:57 PM

Few nitpicks inside otherwise I'm happy.

lldb/include/lldb/Interpreter/OptionGroupValueObjectDisplay.h
51

Should this be with the other bools on line 45?

lldb/include/lldb/Target/Target.h
169

Doxygen comment to explain what the bool returns?

This revision is now accepted and ready to land.Apr 28 2022, 4:57 PM
DavidSpickett accepted this revision.Apr 29 2022, 1:40 AM

All my comments were addressed.

kastiglione added inline comments.May 3 2022, 8:59 AM
lldb/include/lldb/Interpreter/OptionGroupValueObjectDisplay.h
51

It wasn't there because of std::tie can't bind to a bit field value. I've moved this bool into the bitfield and got rid of the std::tie.

Addresses Adrian's feedback.

Fixed/improved docstring