[lldb-dev] Support of a lookup of variables values with PDB
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::getLocationType and so on), but not in the format of DWARF expression. Do I understand correctly, that it is necessary to write some converter of a PDB symbol location to a DWARF expression bytecode? Is this the preferable way of solving the issue? What are pitfalls there? Please, share your thoughts on this. Regards, Aleksandr -- Aleksandr Urakov Software Developer JetBrains http://www.jetbrains.com The Drive to Develop ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Support of a lookup of variables values with PDB
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! > > 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::getLocationType and so on), but not in the format of DWARF > expression. Do I understand correctly, that it is necessary to write some > converter of a PDB symbol location to a DWARF expression bytecode? Is this > the preferable way of solving the issue? What are pitfalls there? Please, > share your thoughts on this. > > > DWARF expressions are pretty powerful and provide all the opcode need to > describe variable locations. You will need to covert the PDB location to > the DWARF expression opcodes. > > Some examples: > variable is at SP + 4 = DW_OP_bregXXX(4) > > DW_OP_bregXXX where XXX is the register number for your stack pointer. > This opcode takes a single operand that is the offset from the register in > question. The variable value is expected to be at the load address in > memory. > > variable is in register 12 = DW_OP_reg12 > > There are 32 DW_OP_regXXX opcodes DW_OP_reg0 - DW_OP_reg31. If your > register value is higher than 32, then use DW_OP_regx which takes a ULEB128 > parameter which is the register number: > > variable is in register 46 = DW_OP_regx(46) > > Global variables: > > variable is at file address 0x1234 = DW_OP_addr(0x1234) > > The address here is a file address, or the file VM address of the global > as it is known in the object file. This address will be slid and covered to > a load address if needed at runtime. > > IF you have any other questions on converting your locations, let me know. > But the above examples should give you a good start. > > Greg > > > Regards, > Aleksandr > > -- > Aleksandr Urakov > Software Developer > JetBrains > http://www.jetbrains.com > The Drive to Develop > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > -- Aleksandr Urakov Software Developer JetBrains http://www.jetbrains.com The Drive to Develop ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Symtab for PECOFF
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
return 0;
}
the evaluation requires JIT (but printing of global variables requires not,
and I can't figure out what is the key difference between a class static
variable and a global variable in the case?).
During symbols resolving IRExecutionUnit::FindInSymbols is used, and it
searches a symbol among functions (which is not our case), and then calls
Module::FindSymbolsWithNameAndType for each module in the list. This
function looks symbols up in a Symtab, which is retrieved through a
SymbolVendor, and it retrieves one from an ObjectFile. ELF files contain
symbols for such a variables in their symbol tables, but the problem is
that PE files usually contain info about exported (and imported) symbols
only, so the lookup in Symtab fails.
I think that we need somehow to retrieve a symbols info from a symbol file.
I thought that we can emit a Symtab from a SymbolFile just like from an
ObjectFile (and for now implement it for SymbolFilePDB only), but I'm not
sure if this solution is good. How can we solve the problem else?
--
Aleksandr Urakov
Software Developer
JetBrains
http://www.jetbrains.com
The Drive to Develop
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Symtab for PECOFF
Thanks for the reply!
Yes, the function search is implemented in the way similar to what you have
described (and even the search in a symbol file is done before the search
in a symtab). But for Module::FindSymbolsWithNameAndType function I can't
find any relevant function in the SymbolFile. Do you mean that we need to
extend the SymbolFile interface with such a function (which will search all
public symbols by the name and the type), and then implement it in derived
classes?
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 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!
>>
>> 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
>> return 0;
>> }
>>
>>
>> the evaluation requires JIT (but printing of global variables requires
>> not, and I can't figure out what is the key difference between a class
>> static variable and a global variable in the case?).
>>
>> During symbols resolving IRExecutionUnit::FindInSymbols is used, and it
>> searches a symbol among functions (which is not our case), and then calls
>> Module::FindSymbolsWithNameAndType for each module in the list. This
>> function looks symbols up in a Symtab, which is retrieved through a
>> SymbolVendor, and it retrieves one from an ObjectFile. ELF files contain
>> symbols for such a variables in their symbol tables, but the problem is
>> that PE files usually contain info about exported (and imported) symbols
>> only, so the lookup in Symtab fails.
>>
>> I think that we need somehow to retrieve a symbols info from a symbol
>> file. I thought that we can emit a Symtab from a SymbolFile just like
>> from an ObjectFile (and for now implement it for SymbolFilePDB only),
>> but I'm not sure if this solution is good. How can we solve the problem
>> else?
>>
>> --
>> Aleksandr Urakov
>> Software Developer
>> JetBrains
>> http://www.jetbrains.com
>> The Drive to Develop
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
--
Aleksandr Urakov
Software Developer
JetBrains
http://www.jetbrains.com
The Drive to Develop
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Symtab for PECOFF
Thanks!
I've almost done this, I'll test it more carefully on the next week and
will create a review.
On Fri, Aug 31, 2018 at 4:54 PM Zachary Turner wrote:
> That would be my thought, yea
> On Fri, Aug 31, 2018 at 1:21 AM Aleksandr Urakov <
> aleksandr.ura...@jetbrains.com> wrote:
>
>> Thanks for the reply!
>>
>> Yes, the function search is implemented in the way similar to what you
>> have described (and even the search in a symbol file is done before the
>> search in a symtab). But for Module::FindSymbolsWithNameAndType function I
>> can't find any relevant function in the SymbolFile. Do you mean that we
>> need to extend the SymbolFile interface with such a function (which will
>> search all public symbols by the name and the type), and then implement it
>> in derived classes?
>>
>> 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 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!
>>>>
>>>> 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
>>>> return 0;
>>>> }
>>>>
>>>>
>>>> the evaluation requires JIT (but printing of global variables requires
>>>> not, and I can't figure out what is the key difference between a class
>>>> static variable and a global variable in the case?).
>>>>
>>>> During symbols resolving IRExecutionUnit::FindInSymbols is used, and
>>>> it searches a symbol among functions (which is not our case), and then
>>>> calls Module::FindSymbolsWithNameAndType for each module in the list.
>>>> This function looks symbols up in a Symtab, which is retrieved through
>>>> a SymbolVendor, and it retrieves one from an ObjectFile. ELF files
>>>> contain symbols for such a variables in their symbol tables, but the
>>>> problem is that PE files usually contain info about exported (and imported)
>>>> symbols only, so the lookup in Symtab fails.
>>>>
>>>> I think that we need somehow to retrieve a symbols info from a symbol
>>>> file. I thought that we can emit a Symtab from a SymbolFile just like
>>>> from an ObjectFile (and for now implement it for SymbolFilePDB only),
>>>> but I'm not sure if this solution is good. How can we solve the problem
>>>> else?
>>>>
>>>> --
>>>> Aleksandr Urakov
>>>> Software Developer
>>>> JetBrains
>>>> http://www.jetbrains.com
>>>> The Drive to Develop
>>>> ___
>>>> lldb-dev mailing list
>>>> lldb-dev@lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>
>>>
>>
>> --
>> Aleksandr Urakov
>> Software Developer
>> JetBrains
>> http://www.jetbrains.com
>> The Drive to Develop
>>
>
--
Aleksandr Urakov
Software Developer
JetBrains
http://www.jetbrains.com
The Drive to Develop
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] `ClangASTSource::IgnoreName` C++ false positives
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 example for the next code:
int main() {
int x = 5;
int id = 7;
int y = 8;
return 0;
}
if you'll break on `return 0` and will try to `print x`, then you'll get a
error like `no member named 'id' in namespace '$__lldb_local_vars'`.
Do you have any ideas, how can we fix it?
Regards,
Alex
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] `ClangASTSource::IgnoreName` C++ false positives
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
regressions Objective-C users would have if we would remove this check from
here?
Regards,
Alex
On Wed, Oct 24, 2018 at 7:14 PM Aleksandr Urakov <
aleksandr.ura...@jetbrains.com> wrote:
> 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 example for the next code:
>
> int main() {
> int x = 5;
> int id = 7;
> int y = 8;
> return 0;
> }
>
> if you'll break on `return 0` and will try to `print x`, then you'll get a
> error like `no member named 'id' in namespace '$__lldb_local_vars'`.
>
> Do you have any ideas, how can we fix it?
>
> Regards,
> Alex
>
--
Aleksandr Urakov
Software Developer
JetBrains
http://www.jetbrains.com
The Drive to Develop
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] `ClangASTSource::IgnoreName` C++ false positives
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 different contexts almost at the same
> time (see my thread several days ago about “problem formatting value
> objects”). That might at least give you some context about why things
>
> I wish ObjC assumptions weren’t so deeply embedded, but alas it is the
> case.
>
> Hopefully Jim or someone has ideas on how to fix this properly.
> On Wed, Oct 31, 2018 at 5:08 AM Aleksandr Urakov <
> aleksandr.ura...@jetbrains.com> wrote:
>
>> 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
>> regressions Objective-C users would have if we would remove this check from
>> here?
>>
>> Regards,
>> Alex
>>
>> On Wed, Oct 24, 2018 at 7:14 PM Aleksandr Urakov <
>> aleksandr.ura...@jetbrains.com> wrote:
>>
>>> 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 example for the next code:
>>>
>>> int main() {
>>> int x = 5;
>>> int id = 7;
>>> int y = 8;
>>> return 0;
>>> }
>>>
>>> if you'll break on `return 0` and will try to `print x`, then you'll get
>>> a error like `no member named 'id' in namespace '$__lldb_local_vars'`.
>>>
>>> Do you have any ideas, how can we fix it?
>>>
>>> Regards,
>>> Alex
>>>
>>
>>
>> --
>> Aleksandr Urakov
>> Software Developer
>> JetBrains
>> http://www.jetbrains.com
>> The Drive to Develop
>>
>
--
Aleksandr Urakov
Software Developer
JetBrains
http://www.jetbrains.com
The Drive to Develop
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] `ClangASTSource::IgnoreName` C++ false positives
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
> smarter about setting the default.
>
> It seems fine to me for lldb to assume - if we know nothing different -
> that we should use ObjC++ as the language to compile expressions. That
> makes sense for most developers, since it only has a few collisions (Class
> and id) that seldom cause problems IRL and gives the widest coverage for of
> expressions. BUT... the behavior when compiling an expression should be
> determined by the expression's language rather than how we set up the
> target ScratchASTContext.
>
> So for instance, if you do:
>
> (lldb) expression --language c++ -- id
>
> that should work, though without the --language you would get an error.
> That doesn't currently work, so apparently we aren't always checking the
> language of the expression.
>
> The situation is a little more complicated than that because sometimes we
> check the frame's language (e.g. we do that in AddLocalVariableDecls, w/o
> checking whether the expression has a specific language. So this
> definitely needs cleaning up.
>
> Then we should also let the Language Runtime's adjust the default
> language, so if you have a program that doesn't load the ObjC runtime, we
> set the default language to C++, not ObjC++.
>
> But the first stage is to make sure we are paying attention to the
> explicit language of the expression throughout the expression parser code.
>
> Jim
>
>
> > On Oct 31, 2018, at 7:25 AM, Zachary Turner wrote:
> >
> > The first thing I would try is to see where the language is getting set
> to objective c and force it c++. Just as an experiment. Depending where it
> happens, it may be possible to initialize it from the debug info (or
> hardcode it).
> >
> > But since ObjC assumptions are baked into several places, this has
> potential to break some things
> > On Wed, Oct 31, 2018 at 6:54 AM Aleksandr Urakov <
> aleksandr.ura...@jetbrains.com> wrote:
> > 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 different contexts almost at the same
> time (see my thread several days ago about “problem formatting value
> objects”). That might at least give you some context about why things
> >
> > I wish ObjC assumptions weren’t so deeply embedded, but alas it is the
> case.
> >
> > Hopefully Jim or someone has ideas on how to fix this properly.
> > On Wed, Oct 31, 2018 at 5:08 AM Aleksandr Urakov <
> aleksandr.ura...@jetbrains.com> wrote:
> > 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
> regressions Objective-C users would have if we would remove this check from
> here?
> >
> > Regards,
> > Alex
> >
> > On Wed, Oct 24, 2018 at 7:14 PM Aleksandr Urakov <
> aleksandr.ura...@jetbrains.com> wrote:
> > 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 example for the next code:
> > int main() {
> > int x = 5;
> > int id = 7;
> > int y = 8;
> > return 0;
> > }
> > if you'll break on `return 0` and will try to `print x`, then you'll get
> a error like `no member named 'id' in namespace '$__lldb_local_vars'`.
> >
> > Do you have any ideas, how can we fix it?
> >
> > Regards,
> > Alex
> >
> >
> > --
> > Aleksandr Urakov
> > Software Developer
> > JetBrains
> > http://www.jetbrains.com
> > The Drive to Develop
> >
> >
> > --
> > Aleksandr Urakov
> > Software Developer
> > JetBrains
> > http://www.jetbrains.com
> > The Drive to Develop
>
>
--
Aleksandr Urakov
Software Developer
JetBrains
http://www.jetbrains.com
The Drive to Develop
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
