[Lldb-commits] [PATCH] D32732: "target variable" not showing all global variable if we print any global variable before execution starts

[Jim Ingham via Phabricator via lldb-commits]

jingham added a reviewer: jingham.
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.

I actually think the behavior you are seeing is the designed behavior, but it isn't clearly documented.

Target variable is designed to help manage the large number of global & static variables that you can have in a complex system.  So we avoid having the command with no arguments just dumping all the global variables in every library in the program in most cases.  That can be pages and pages of output...

The current method for this is: before you run, when target variable has no context, it will either search for globals & statics by name if you provide them, or show all the globals in whatever shared libraries you name.  It doesn't ever show all globals everywhere in this case:

   > lldb ~/Projects/Sketch/build/Debug/Sketch.app
  (lldb) target create "/Volumes/ThePlayground/Users/jingham/Projects/Sketch/build/Debug/Sketch.app"
  Current executable set to '/Volumes/ThePlayground/Users/jingham/Projects/Sketch/build/Debug/Sketch.app' (x86_64).
  (lldb) target variable
  error: 'target variable' takes one or more global variable names as arguments
  
  (lldb) target variable SKTAppAutosavingDelayPreferenceKey
  (NSString *) SKTAppAutosavingDelayPreferenceKey = 0x00000001000223f8
  (lldb) target variable --shlib Sketch
  Global variables for /Volumes/ThePlayground/Users/jingham/Projects/Sketch/build/Debug/Sketch.app/Contents/MacOS/Sketch
  (NSString *) SKTAppAutosavingDelayPreferenceKey = 0x00000001000223f8
  (NSString *) SKTAppAutosavesPreferenceKey = 0x00000001000223d8
  ...

That first error could be a little nicer, actually...

Then when you are in a frame scope, what we show by default is the statics and globals defined in the CU holding that frame.  That is why you aren't seeing other variables once you've stopped.

If you want to broaden the search you can either specify a name, or specify a shared library.

I think the current behavior is preferable to dumping all the globals, which if you have debug information for a substantial part of the system is overwhelming and not useful.

I'm also confused about the changes to the expression parser lookup.  The expression parser isn't trying to limit information in the way "target variable" does, and should already look everywhere for globals (of course starting from the current frame -> containing CU -> containing dylib and finally out to all dylibs.  I don't see any indication from your examples that this isn't working, and your test only test "target variable", it doesn't use the expression parser.


Repository:
  rL LLVM

https://reviews.llvm.org/D32732