[Lldb-commits] [PATCH] D133164: Add the ability to show when variables fails to be available when debug info is valid.

Fri Sep 9 05:59:57 PDT 2022

labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

Looks good. Thanks.

================
Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:4161
+  if (command) {
+    if (command->contains(" -gline-tables-only"))
+      return Status("-gline-tables-only enabled, no variable information is "
----------------
clayborg wrote:
> labath wrote:
> > clayborg wrote:
> > > labath wrote:
> > > > This isn't a particularly reliable way of detecting whether variable information was emitted. For example a command line `clang -gline-tables-only -g2` will in fact produce full debug info and `clang -g1` will not. Could we make that determination based on the presence of actual variable DIEs in the debug info? Perhaps query the index whether it knows of any (global) variable or any type defined within the compile unit?
> > > This function only gets called when there are no variables in a stack frame at all and checks for reasons why. So if "-gline-tables-only -g2" is used, this function won't get called if there were variables.
> > > 
> > > I planned to make a follow up patch that detected no variables in a compile uint by checking the compile unit's abbreviation set to see if it had any DW_TAG_variable or DW_TAG_formal_parameter definitions, and if there weren't any respond with "-gline-tables-only might be enabled....". 
> > > 
> > > If we see this option for sure and have the side affect of there being no variables, I would like to user the users know what they can do to fix things if at all possible. 
> > I get that, but this check is not completely correct in either direction. For example, `clang -g1` will not produce variable information, but this code will not detect it. Same goes for `clang -gmlt`. And I probably missed some other ways one can prevent variable info from being generated. Keeping up with all the changes in clang flags will just be a game of whack-a-mole. If we checked the actual debug info, then we would catch all of these cases, including the (default) case when the compiler did not embed command line information into the debug info.
> > 
> > And I don't think we need to know the precise command line to give meaningful advice to the users. In all of these cases, sticking an extra `-g` at the end of the command line will cause the variables to reappear. If we wanted to, we could also put a link to the lldb web page where we can (at length) describe the various reasons why variables may not be available and how to fix them.
> I switched over to just looking for any variable DIEs anywhere in the CU. This should cover all options. Let me know if you think we should add a top level web page and reference it in the error message?
I think it might be nice to have some kind of a "I can't debug" troubleshooting page, but I don't think we need to tie it to the future of this patch. 

================
Comment at: lldb/test/API/commands/frame/var/TestFrameVar.py:173
+        '''
+        self.build(dictionary={'CFLAGS_EXTRAS': '-gline-tables-only -grecord-command-line'})
+        exe = self.getBuildArtifact("a.out")
----------------
I guess this isn't necessary any more.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133164/new/

https://reviews.llvm.org/D133164