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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
