clayborg added inline comments.
================
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 "
----------------
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?
================
Comment at: lldb/test/API/functionalities/archives/Makefile:12
$(AR) $(ARFLAGS) $@ $^
- $(RM) $^
+ # $(RM) $^
----------------
labath wrote:
> I don't know how important this is, but I believe the build was deleting the
> .o files to ensure that we access the copies within the archive. If you think
> that's fine, then just delete this line.
Yeah, part of my test touches the .o file and only rebuilds the libfoo.a so I
have to leave the .o files there.
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
