[Lldb-commits] [PATCH] D17363: Add SymbolFilePDB with basic support for line tables.

[Zachary Turner via lldb-commits]

On Thu, Feb 18, 2016 at 6:16 PM Greg Clayton <clayborg at gmail.com> wrote:

>
> > Just to make sure I understand, is it safe to say that:
> >
> > If check_inlines is false, sc_list should return with exactly 1
> SymbolContext with m_comp_unit set to the main source file?
>
> You would get one SymbolContext per compile unit whose path matches the
> file_spec _and_ contains a line number. There might be multiple "Foo.cpp"
> files in different directories withing one PDB file, so you might still end
> up finding N matches. So your existing code can be used when check_inlines
> if false as long as the PDB can search by fullname and by basename. I am
> guessing it doesn't though, am I wrong?
>
> > The same for the check_inlines is false calse -- we still just have
> SymbolContext but we add line table entries from all additional files that
> contribute to the compilation unit?
> > When will sc_list end up with multiple entries?
>
> You always look through all compile units. If check_inlines is false, then
> you make sure "file_spec" matches (by basename  if only basename is
> specified, or by full path if a directory and filename are valid inside
> file_spec. If the file matches, then look for any lines that match and
> return ALL instances of them. Auto inlining of a function inside a compile
> unit might cause there to be many entries for line 10.
>

I'm coming back around to this now.  What happens if check_inlines is
False, but the FileSpec is a header file like <vector>.  You said "If
check_inlines is false, make sure file_spec matches".  But if file_spec is
a header file, it's never going to match anything.  Should I simply expect
that the API is not called in this way?  i.e. if I write b vector:1234 then
I can expect that check_inlines will be true?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20160226/a49f4fdd/attachment.html>