clayborg added a comment.
Bonus point for implementing a global symbol search that is aware of the above
rules and can stop after step 1 if there are matches, and after step 2 if there
are matches, etc.
https://reviews.llvm.org/D33083
___
lldb-com
clayborg added a comment.
In https://reviews.llvm.org/D33083#751836, @jingham wrote:
> Actually, I take that back. Why do you have to call FindGlobalDataSymbol
> twice? Shouldn't FindGlobalDataSymbol do that work for you. After all you
> passed in the module. It should itself prefer symbols
jingham added a comment.
Actually, I take that back. Why do you have to call FindGlobalDataSymbol
twice? Shouldn't FindGlobalDataSymbol do that work for you. After all you
passed in the module. It should itself prefer symbols in the module...
It also seems wrong that we're just picking the
jingham added a comment.
Yes, this seems obviously right.
https://reviews.llvm.org/D33083
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
clayborg added a comment.
There is a SymbolContext function sorts types based on the context contained in
a SymbolContext. Seems like we should do the same thing here? See
SymbolContext::SortTypeList().
https://reviews.llvm.org/D33083
___
lldb-com
spyffe created this revision.
When it resolved symbol-only variables, the expression parser currently looks
only in the global module list. It should prefer the current module.
I've fixed that behavior by making it search the current module first, and only
search globally if it finds nothing.
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.
Very nice
Repository:
rL LLVM
https://reviews.llvm.org/D33025
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.
spyffe created this revision.
`ptr_refs` exposed a problem in ClangASTContext's implementation; it uses an
accessor to convert a `QualType` into an `ObjCObjectPointerType`, but the
accessor is not fully general. `getAs()` is the safer way to go.
I've added a test case that uses `ptr_refs` in a
krytarowski added a comment.
In https://reviews.llvm.org/D33035#751280, @clayborg wrote:
> In https://reviews.llvm.org/D33035#751264, @krytarowski wrote:
>
> > Can we please use the generic process plugin code, not the specific Linux
> > one? If the generic code is insufficient - we should adjus
clayborg added a comment.
In https://reviews.llvm.org/D33035#751264, @krytarowski wrote:
> Can we please use the generic process plugin code, not the specific Linux
> one? If the generic code is insufficient - we should adjust it and alter
> instances of it (Linux and BSD).
There should be no
krytarowski added a comment.
Can we please use a generic process plugin code, not the specific Linux one? If
the generic code is insufficient - we should adjust it and alter instances of
it (Linux and BSD).
https://reviews.llvm.org/D33035
___
lldb
clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.
So we don't want clients of SBStructuredData to have to text scrape and write
manual decoders. See my inlined comments on the minimal modifications we need
to make to SBStructure
abhishek.aggarwal abandoned this revision.
abhishek.aggarwal added a comment.
Abandoning this change due to formatting problem with commit message.
https://reviews.llvm.org/D33034
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://list
13 matches
Mail list logo