Hello!
We want to add to LLDB a support of a lookup of variables values with PDB.
Now SymbolFilePDB::ParseVariableForPDBData function uses an empty location
for variables, so e.g. `fr v` prints values as ''. Symbol
location information is available in a PDB (through
PDBSymbolData::getLocationTyp
Thank you for explanations!
I'll create the converter to DWARF expressions.
Regards,
Aleksandr
On Wed, Jun 27, 2018 at 5:38 PM Greg Clayton wrote:
>
>
> On Jun 27, 2018, at 5:25 AM, Aleksandr Urakov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hello!
Hello!
I'm working on an expressions evaluation on Windows, and currently I'm
trying to make a JIT evaluation working.
When I'm trying to evaluate the next expression:
print S::x
on the next code:
struct S {
static int x;
void foo() { }
};
int S::x = 5;
int main() {
S().foo(); // here
l is not found in the
> executables symtab, it will fall back to searching in the symbol file..
> this logic doesn’t even need to be specific to PDB
> On Thu, Aug 30, 2018 at 7:00 AM Aleksandr Urakov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hello!
>>
&g
; On Thu, Aug 30, 2018 at 6:03 PM Zachary Turner
>> wrote:
>>
>>> It seems reasonable to me to say that if the symbol is not found in the
>>> executables symtab, it will fall back to searching in the symbol file..
>>> this logic doesn’t even need to
Hi all!
There are two hardcoded names to ignore in the
`ClangASTSource::IgnoreName` function, "Class" and "id", they are valid
names for C++. It seems that they were added for the Objective-C case. But
the problem is that when they are in locals they are blocking expressions
evaluation.
For examp
Hello,
I've tried to use a check like `if (m_ast_context->getLangOpts().ObjC)
...`, but it seems that it's always true. How can we else determine here if
the Objective-C case is used? Or if we can't, where can we move `if (name
== id_name || name == Class_name)` to make it Objective-C only? What
r
Sorry, I have somehow missed the discussion continuation there. Yes, it's a
very similar problem, thanks. But unfortunately no one of the workarounds
mentioned there doesn't work in this situation...
On Wed, Oct 31, 2018 at 4:32 PM Zachary Turner wrote:
> It seems like we hit this issue in diffe
Thanks for details! So at first I'll try to propagate the "language"
setting of an expression there.
On Wed, Oct 31, 2018 at 9:04 PM Jim Ingham wrote:
> We need to do more work to make sure the "language" setting for
> expressions gets propagated everywhere and obeyed. We could also be
> smarte
