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
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
>
___
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
