[lldb-dev] FW: Search C++ "virtual" objects
On Linux, given a core dump file, an executable and its symbols, is it possible to do the following in LLDB (maybe with a LLDB extension)? 1. Get the list of all C++ virtual types (classes with virtual function table) 2. Search the whole address space to find all instances of such objects? (false positives are okay) If #1 is not possible, then how about getting virtual function table address of a given type (without an object)? Thanks much. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Search C++ "virtual" objects
Thanks much for all the useful information!
I was able to get all vtable information with the following command, but is
there an API I could use in an extension? I have checked the obvious ones
“SBSymbol*”, they do not seem to have functions for iterating/searching symbols.
image lookup -A -r -v -s "vtable"
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
From: Greg Clayton<mailto:gclay...@apple.com>
Sent: Friday, August 12, 2016 05:25 PM
To: Lei Kong<mailto:leik...@msn.com>
Cc: lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>
Subject: Re: [lldb-dev] Search C++ "virtual" objects
> On Aug 12, 2016, at 4:55 PM, Lei Kong via lldb-dev
> wrote:
>
> On Linux, given a core dump file, an executable and its symbols, is it
> possible to do the following in LLDB (maybe with a LLDB extension)?
>
> 1. Get the list of all C++ virtual types (classes with virtual function
> table)
You will be able to find all vtable symbols in the symbol tables of the
executable and shared libraries that you have. Not sure if the system libraries
on linux have the vtable symbols in the symbol tables of the shared libraries.
If you can download the separate debug info for the shared libraries that might
help.
If you made a core file on your current machine and you are trying to look at
this core file on the same machine without any shared libraries having been
updated, then you might if the vtable symbols are in your executables in the
symbol tables as you said.
So the answer is maybe. Depends on how good your symbol tables are for the
executables and sharerd libraries that contain virtual classes that you care
about.
> 2. Search the whole address space to find all instances of such
> objects? (false positives are okay)
You should be able to iterate through all of the memory segments using:
lldb::SBMemoryRegionInfoList
GetMemoryRegions();
This is a relatively new thing that was added to LLDB in the last few months so
you will need a pretty recent LLDB. But this will give you all of the memory
regions in your current process. You can then look at the permissions of each
regions to make sure the regions is writable. So you can try this in python:
(lldb)
regions = lldb.process.GetMemoryRegions();
num_regions = regions.GetSize()
region = lldb.SBMemoryRegionInfo()
error = lldb.SBError()
for i in range(num_regions):
if regions.GetMemoryRegionAtIndex(i, region):
if region.IsWritable():
addr = region.GetRegionBase()
end_addr = region.GetRegionEnd()
bytes = process.ReadMemory(addr, end_addr - addr, error)
// Bytes is a binary python string so you can search it for the vtable
pointer of your choosing
>
> If #1 is not possible, then how about getting virtual function table address
> of a given type (without an object)?
There should be symbols in the symbol tables that are the vtable symbols and
you can look them up by name. For example, on MacOSX, if you compile the
following:
class A
{
public:
A(int a) : m_a(a) {}
virtual ~A() {}
protected:
int m_a;
};
int main (int argc, char const *argv[], char const *envp[])
{
A *a_ptr= new A(123);
return 0;
}
You get a symbol table of:
(lldb) image dump symtab a.out
Symtab, file = /private/tmp/a.out, num_symbols = 19:
Debug symbol
|Synthetic symbol
||Externally Visible
|||
Index UserID DSX TypeFile Address/Value Load Address Size
Flags Name
--- -- --- --- -- --
-- -- --
[0] 0 D SourceFile 0x
Sibling -> [ 12] 0x0064 /tmp/main.cpp
[1] 2 D ObjectFile 0x57ae67f1
0x 0x00660001
/var/folders/2y/y20b92093flcz2qdwwpf5b6c0007k2/T/main-fb7ae1.o
[2] 4 D X Code0x00010e00 0x00010e00
0x0080 0x000f main
[3] 8 D Code0x00010e80 0x00010e80
0x0030 0x001e0080 A::A(int)
[4] 12 D Code0x00010eb0 0x00010eb0
0x0030 0x001e0080 A::A(int)
[5] 16 D Code0x00010ee0 0x00010ee0
0x0020 0x001e0080 A::~A()
[6] 20 D Code0x00010f00 0x00010f00
0x0030 0x001e0080 A::~A()
[7] 24 D Code0x00010f30 0x00010f30
0x000a 0x001e0080 A::~A()
[8] 27 D Data0x00010f68 0x00010f68
0x002c 0x000e GCC_except_table0
[9] 28 D X Data0x00010f94 0x00010f94
0x0003 0x000f0080 typeinfo name for A
[ 10] 29 D
Re: [lldb-dev] Search C++ "virtual" objects
Should I use lldb::SBTarget::GetModuleAtIndex() to get all modules and then
lldb::SBModule::GetSymbolAtIndex() to go through all symbols?
Thanks.
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
From: Lei Kong via lldb-dev<mailto:lldb-dev@lists.llvm.org>
Sent: Monday, August 15, 2016 04:44 PM
To: Greg Clayton<mailto:gclay...@apple.com>
Cc: lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>
Subject: Re: [lldb-dev] Search C++ "virtual" objects
Thanks much for all the useful information!
I was able to get all vtable information with the following command, but is
there an API I could use in an extension? I have checked the obvious ones
“SBSymbol*”, they do not seem to have functions for iterating/searching symbols.
image lookup -A -r -v -s "vtable"
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
From: Greg Clayton<mailto:gclay...@apple.com>
Sent: Friday, August 12, 2016 05:25 PM
To: Lei Kong<mailto:leik...@msn.com>
Cc: lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>
Subject: Re: [lldb-dev] Search C++ "virtual" objects
> On Aug 12, 2016, at 4:55 PM, Lei Kong via lldb-dev
> wrote:
>
> On Linux, given a core dump file, an executable and its symbols, is it
> possible to do the following in LLDB (maybe with a LLDB extension)?
>
> 1. Get the list of all C++ virtual types (classes with virtual function
> table)
You will be able to find all vtable symbols in the symbol tables of the
executable and shared libraries that you have. Not sure if the system libraries
on linux have the vtable symbols in the symbol tables of the shared libraries.
If you can download the separate debug info for the shared libraries that might
help.
If you made a core file on your current machine and you are trying to look at
this core file on the same machine without any shared libraries having been
updated, then you might if the vtable symbols are in your executables in the
symbol tables as you said.
So the answer is maybe. Depends on how good your symbol tables are for the
executables and sharerd libraries that contain virtual classes that you care
about.
> 2. Search the whole address space to find all instances of such
> objects? (false positives are okay)
You should be able to iterate through all of the memory segments using:
lldb::SBMemoryRegionInfoList
GetMemoryRegions();
This is a relatively new thing that was added to LLDB in the last few months so
you will need a pretty recent LLDB. But this will give you all of the memory
regions in your current process. You can then look at the permissions of each
regions to make sure the regions is writable. So you can try this in python:
(lldb)
regions = lldb.process.GetMemoryRegions();
num_regions = regions.GetSize()
region = lldb.SBMemoryRegionInfo()
error = lldb.SBError()
for i in range(num_regions):
if regions.GetMemoryRegionAtIndex(i, region):
if region.IsWritable():
addr = region.GetRegionBase()
end_addr = region.GetRegionEnd()
bytes = process.ReadMemory(addr, end_addr - addr, error)
// Bytes is a binary python string so you can search it for the vtable
pointer of your choosing
>
> If #1 is not possible, then how about getting virtual function table address
> of a given type (without an object)?
There should be symbols in the symbol tables that are the vtable symbols and
you can look them up by name. For example, on MacOSX, if you compile the
following:
class A
{
public:
A(int a) : m_a(a) {}
virtual ~A() {}
protected:
int m_a;
};
int main (int argc, char const *argv[], char const *envp[])
{
A *a_ptr= new A(123);
return 0;
}
You get a symbol table of:
(lldb) image dump symtab a.out
Symtab, file = /private/tmp/a.out, num_symbols = 19:
Debug symbol
|Synthetic symbol
||Externally Visible
|||
Index UserID DSX TypeFile Address/Value Load Address Size
Flags Name
--- -- --- --- -- --
-- -- --
[0] 0 D SourceFile 0x
Sibling -> [ 12] 0x0064 /tmp/main.cpp
[1] 2 D ObjectFile 0x57ae67f1
0x 0x00660001
/var/folders/2y/y20b92093flcz2qdwwpf5b6c0007k2/T/main-fb7ae1.o
[2] 4 D X Code0x00010e00 0x00010e00
0x0080 0x000f main
[3] 8 D Code0x00010e80 0x00010e80
0x0030 0x001e0080 A::A(int)
[4] 12 D Code0x00010eb0 0x00010eb0
0x0030 0x001e0080 A::A(int)
[5] 16 D Code0x00010ee0 0x00010ee0
0x
Re: [lldb-dev] Search C++ "virtual" objects
I’d like to add FindSymbolsByRegex, please let me know what I need to do.
Thanks.
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
From: Greg Clayton<mailto:gclay...@apple.com>
Sent: Tuesday, August 16, 2016 11:42 AM
To: Lei Kong<mailto:leik...@msn.com>
Cc: Lei Kong via lldb-dev<mailto:lldb-dev@lists.llvm.org>
Subject: Re: [lldb-dev] Search C++ "virtual" objects
> On Aug 15, 2016, at 4:59 PM, Lei Kong wrote:
>
> Should I use lldb::SBTarget::GetModuleAtIndex() to get all modules and then
> lldb::SBModule::GetSymbolAtIndex() to go through all symbols?
> Thanks.
This is the only way right now as we don't have a SBModule::FindSymbols that
takes a regular expression. We only currently have:
lldb::SBSymbolContextList
FindSymbols (const char *name,
lldb::SymbolType type = eSymbolTypeAny);
If you want to, you can add a:
lldb::SBSymbolContextList
FindSymbolsByRegex (const char *regex, lldb::SymbolType type =
eSymbolTypeAny);
Then you could call this:
SBModule module = ...;
lldb::SBSymbolContextList symbols = module.FindSymbolsByRegex("^vtable for ");
You can then also add this to SBTarget. Let me know if you are interested in
adding this and I can help you do it.
Greg Clayton
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] lldb type summary provider - SBProcess is invalid
I wrote a lldb type summary provider for wstring with 16bit wchar on Ubuntu 16.04.Things work fine if I manually do the following in lldb:(lldb) script import mytypes (lldb) type summary add -F mytypes.wstring_SummaryProvider "std::__1::wstring" I tried to make things easier with auto-loading by adding the following to .lldbinit:script import mytypes type summary add -F mytypes.wstring_SummaryProvider "std::__1::wstring" Then I got a failure of "SBProcess is invalid" when printing a wstring variable.My type summary function has the following, which I believe is where the error is encountered:content = lldb.process.ReadMemory(bufferAddr, byteCount, error) Maybe this is because "process" is not assigned yet when the type summary is added during auto-loading? Or this is a bug in lldb? Does anyone know how to work around this issue? Thanks much ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb type summary provider - SBProcess is invalid
Thanks! SBValue.process works! I have another script that I run manually to search process memory for certain patterns, not a type summary provider, there is no SBValue passed to my script, in such a case, how do I get current process? From: Enrico Granata<mailto:egran...@apple.com> Sent: Tuesday, September 13, 2016 10:31 AM To: Lei Kong<mailto:leik...@msn.com> Cc: lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org> Subject: Re: [lldb-dev] lldb type summary provider - SBProcess is invalid > On Sep 13, 2016, at 10:02 AM, Lei Kong via lldb-dev > wrote: > > I wrote a lldb type summary provider for wstring with 16bit wchar on Ubuntu > 16.04. > > Things work fine if I manually do the following in lldb: > > (lldb) script import mytypes > (lldb) type summary add -F mytypes.wstring_SummaryProvider "std::__1::wstring" > I tried to make things easier with auto-loading by adding the following to > .lldbinit: > > script import mytypes > type summary add -F mytypes.wstring_SummaryProvider "std::__1::wstring" > Then I got a failure of "SBProcess is invalid" when printing a wstring > variable. > > My type summary function has the following, which I believe is where the > error is encountered: > > content = lldb.process.ReadMemory(bufferAddr, byteCount, error) > Maybe this is because "process" is not assigned yet when the type summary is > added during auto-loading? Or this is a bug in lldb? Does anyone know how to > work around this issue? > > Good hunch :-) Maybe we should do a better job at documenting this, but http://lldb.llvm.org/python-reference.html <http://lldb.llvm.org/python-reference.html> reads "While extremely convenient, these variables (lldb.process et alia) have a couple caveats that you should be aware of. First of all, they hold the values of the selected objects on entry to the embedded interpreter. They do not update as you use the LLDB API's to change, for example, the currently selected stack frame or thread. Moreover, they are only defined and meaningful while in the interactive Python interpreter. There is no guarantee on their value in any other situation, hence you should not use them when defining Python formatters, breakpoint scripts and commands (or any other Python extension point that LLDB provides). As a rationale for such behavior, consider that lldb can run in a multithreaded environment, and another thread might call the "script" command, changing the value out from under you." As part of a formatter, you get passed an SBValue. One of the things you can ask of an SBValue is the process it came from, thusly: value.GetProcess() That's the SBProcess object you want to use > > Thanks much > > > > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > <http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev> Thanks, - Enrico 📩 egranata@.com ☎️ 27683 ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb type summary provider - SBProcess is invalid
Does the following qualify as "interactive usage"? It seems using "process" works in myfile.func(), or I was just lucky? Thanks. (lldb) script myfile.func(args) > Subject: Re: [lldb-dev] lldb type summary provider - SBProcess is invalid > From: gclay...@apple.com > Date: Wed, 14 Sep 2016 09:33:20 -0700 > CC: egran...@apple.com; lldb-dev@lists.llvm.org > To: leik...@msn.com > > > > On Sep 13, 2016, at 9:50 PM, Lei Kong via lldb-dev > > wrote: > > > > Thanks! > > SBValue.process works! > > > > I have another script that I run manually to search process memory for > > certain patterns, not a type summary provider, there is no SBValue passed > > to my script, in such a case, how do I get current process? > > > If this is python a command line command you are making, use the variant that > takes an execution context: > > def my_command(debugger, command, exe_ctx, result, dict): > # Always use the specified execution context to get the target, process > # thread and frame. If this command gets run from a breakpoint callback > # these will not match the debugger's selected target, the selected > # process in the target, the selected thread in the process and the > # selected frame in the thread. > target = exe_ctx.GetTarget() > process = exe_ctx.GetProcess() > thread = exe_ctx.GetThread() > frame = exe_ctx.GetFrame() > > > The execution context is explicitly specified for you. > > > From: Enrico Granata > > Sent: Tuesday, September 13, 2016 10:31 AM > > To: Lei Kong > > Cc: lldb-dev@lists.llvm.org > > Subject: Re: [lldb-dev] lldb type summary provider - SBProcess is invalid > > > > > >> On Sep 13, 2016, at 10:02 AM, Lei Kong via lldb-dev > >> wrote: > >> > >> I wrote a lldb type summary provider for wstring with 16bit wchar on > >> Ubuntu 16.04. > >> > >> Things work fine if I manually do the following in lldb: > >> > >> (lldb) script import mytypes > >> (lldb) type summary add -F mytypes.wstring_SummaryProvider > >> "std::__1::wstring" > >> > >> I tried to make things easier with auto-loading by adding the following to > >> .lldbinit: > >> > >> script import mytypes > >> type summary add -F mytypes.wstring_SummaryProvider "std::__1::wstring" > >> > >> Then I got a failure of "SBProcess is invalid" when printing a wstring > >> variable. > >> > >> My type summary function has the following, which I believe is where the > >> error is encountered: > >> > >> content = lldb.process.ReadMemory(bufferAddr, byteCount, error) > >> > >> Maybe this is because "process" is not assigned yet when the type summary > >> is added during auto-loading? Or this is a bug in lldb? Does anyone know > >> how to work around this issue? > >> > >> > > > > Good hunch :-) > > Maybe we should do a better job at documenting this, but > > http://lldb.llvm.org/python-reference.html reads > > > > "While extremely convenient, these variables (lldb.process et alia) have a > > couple caveats that you should be aware of. First of all, they hold the > > values of the selected objects on entry to the embedded interpreter. They > > do not update as you use the LLDB API's to change, for example, the > > currently selected stack frame or thread. > > Moreover, they are only defined and meaningful while in the interactive > > Python interpreter. There is no guarantee on their value in any other > > situation, hence you should not use them when defining Python formatters, > > breakpoint scripts and commands (or any other Python extension point that > > LLDB provides). As a rationale for such behavior, consider that lldb can > > run in a multithreaded environment, and another thread might call the > > "script" command, changing the value out from under you." > > > > As part of a formatter, you get passed an SBValue. One of the things you > > can ask of an SBValue is the process it came from, thusly: > > > > value.GetProcess() > > > > That's the SBProcess object you want to use > > > >> > >> Thanks much > >> > >> > >> > >> > >> ___ > >> lldb-dev mailing list > >> lldb-dev@lists.llvm.org > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > > > > Thanks, > > - Enrico > > 📩 egranata@.com ☎️ 27683 > > > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t'
I ran into the error in the subject when running a python script with "script myfile.myscript()". The value addr_t parameter used is 0x01223f68, the following works fine: (lldb) scr Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D. >>> e = lldb.SBError() >>> ptr = lldb.process.ReadPointerFromMemory(0x01223f68, e) >>> print ptr 0 >>> Any suggestion how to further investigate? Thanks. myfile.myscript() calls the following function in a loop (iterate through all vtable symbols), which contains the call ReadPointerFromMemory. def dump_vtbl(vtableAddr) : error = lldb.SBError() vtableEndAddr = lldb.process.ReadPointerFromMemory(vtableAddr+8, error) if not error.success : return False print "vtable: [%0.16x, %0.16x)" % (vtableAddr, vtableEndAddr) for addr in range(vtableAddr, vtableEndAddr, 8) : print "read from address %.016x" % addr try: funcAddr = lldb.process.ReadPointerFromMemory(addr, error) except: sys.exc_clear() continue if not error.success : continue ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t'
I tried printing error.descryption, but it didn't work, because when the error happens, it seems ReadPointerFromMemory never returned to my code. read from address 01223f68 Traceback (most recent call last): File "", line 1, in File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 289, in findall findtypes(pattern,ignorePureVirtualType) File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 246, in findtypes if ignorePureVirtualType and has_pure_virtual(vtableAddr, pureVirtualFuncs) : File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 190, in has_pure_virtual vtableEndAddr = lldb.process.ReadPointerFromMemory(vtableAddr-8, error) File "/home/leikong/bin/lldb/lib/python2.7/site-packages/lldb/__init__.py", line 9418, in ReadPointerFromMemory return _lldb.SBProcess_ReadPointerFromMemory(self, addr, error) OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t' > Subject: Re: [lldb-dev] OverflowError: in method > 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t' > From: jing...@apple.com > Date: Fri, 16 Sep 2016 17:12:24 -0700 > CC: lldb-dev@lists.llvm.org > To: leik...@msn.com > > You passed an error into ReadPointerFromMemory. In the cases where you > aren't getting what you expect, what does that error say? > > Jim > > > On Sep 16, 2016, at 5:06 PM, Lei Kong via lldb-dev > > wrote: > > > > I ran into the error in the subject when running a python script with > > "script myfile.myscript()". > > > > The value addr_t parameter used is 0x01223f68, the following works > > fine: > > > > (lldb) scr > > Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D. > > >>> e = lldb.SBError() > > >>> ptr = lldb.process.ReadPointerFromMemory(0x01223f68, e) > > >>> print ptr > > 0 > > >>> > > > > Any suggestion how to further investigate? Thanks. > > > > myfile.myscript() calls the following function in a loop (iterate through > > all vtable symbols), which contains the call ReadPointerFromMemory. > > > > def dump_vtbl(vtableAddr) : > > error = lldb.SBError() > > vtableEndAddr = lldb.process.ReadPointerFromMemory(vtableAddr+8, error) > > if not error.success : > > return False > > print "vtable: [%0.16x, %0.16x)" % (vtableAddr, vtableEndAddr) > > for addr in range(vtableAddr, vtableEndAddr, 8) : > > print "read from address %.016x" % addr > > try: > > funcAddr = lldb.process.ReadPointerFromMemory(addr, error) > > except: > > sys.exc_clear() > > continue > > if not error.success : > > continue > > > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t'
You are right, it seems the argument is out of range, both vtableAddr and vtableAddr-8 are “8.5” byte long. Maybe there is something wrong with the way I get vtableAddress? I will clean up my full script and send it to you if the following does not provide enough information, thanks much. def vtable_addr (vtableSymbol): return vtableSymbol.addr.section.file_addr + vtableSymbol.addr.offset + 0x10 vtableAddr, type=, value=0x1000f vtableAddr-8, type=, value=0x10007 Traceback (most recent call last): File "", line 1, in File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 199, in findall findtypes(pattern,ignorePureVirtualType) File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 156, in findtypes if ignorePureVirtualType and has_pure_virtual(vtableAddr, pureVirtualFuncs) : File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line 100, in has_pure_virtual vtableEndAddr = lldb.process.ReadPointerFromMemory(vtableAddr-8, error) File "/home/leikong/bin/lldb/lib/python2.7/site-packages/lldb/__init__.py", line 9418, in ReadPointerFromMemory return _lldb.SBProcess_ReadPointerFromMemory(self, addr, error) OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t' From: Greg Clayton<mailto:gclay...@apple.com> Sent: Monday, September 19, 2016 09:12 AM To: Lei Kong<mailto:leik...@msn.com> Cc: Jim Ingham<mailto:jing...@apple.com>; lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org> Subject: Re: [lldb-dev] OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t' Try printing the type of the value you are passing in the line: vtableEndAddr = lldb.process.ReadPointerFromMemory(vtableAddr-8, error) print type(vtableAddr) print type(vtableAddr-8) It seems like it thinks vtableAddr doesn't fit into a lldb::addr_t which is a uint64_t > On Sep 16, 2016, at 7:39 PM, Lei Kong via lldb-dev > wrote: > > I tried printing error.descryption, but it didn't work, because when the > error happens, it seems ReadPointerFromMemory never returned to my code. > > > read from address 01223f68 > Traceback (most recent call last): > File "", line 1, in > File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line > 289, in findall > findtypes(pattern,ignorePureVirtualType) > File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line > 246, in findtypes > if ignorePureVirtualType and has_pure_virtual(vtableAddr, > pureVirtualFuncs) : > File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line > 190, in has_pure_virtual > vtableEndAddr = lldb.process.ReadPointerFromMemory(vtableAddr-8, error) > File "/home/leikong/bin/lldb/lib/python2.7/site-packages/lldb/__init__.py", > line 9418, in ReadPointerFromMemory > return _lldb.SBProcess_ReadPointerFromMemory(self, addr, error) > OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of > type 'lldb::addr_t' > > > > Subject: Re: [lldb-dev] OverflowError: in method > > 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t' > > From: jing...@apple.com > > Date: Fri, 16 Sep 2016 17:12:24 -0700 > > CC: lldb-dev@lists.llvm.org > > To: leik...@msn.com > > > > You passed an error into ReadPointerFromMemory. In the cases where you > > aren't getting what you expect, what does that error say? > > > > Jim > > > > > On Sep 16, 2016, at 5:06 PM, Lei Kong via lldb-dev > > > wrote: > > > > > > I ran into the error in the subject when running a python script with > > > "script myfile.myscript()". > > > > > > The value addr_t parameter used is 0x01223f68, the following > > > works fine: > > > > > > (lldb) scr > > > Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or > > > Ctrl-D. > > > >>> e = lldb.SBError() > > > >>> ptr = lldb.process.ReadPointerFromMemory(0x01223f68, e) > > > >>> print ptr > > > 0 > > > >>> > > > > > > Any suggestion how to further investigate? Thanks. > > > > > > myfile.myscript() calls the following function in a loop (iterate through > > > all vtable symbols), which contains the call ReadPointerFromMemory. > > > > > > def dump_vtbl(vtableAddr) : > > > error =
Re: [lldb-dev] OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t'
Sharing the findings on lldb-dev. Greg helped me figure out the issue, I need to check if symbol address is lldb.LLDB_INVALID_ADDRESS. Things work fine now after the added checking. The remaining issue is to figure out whether symbol.addr.file_addr or symbol.addr.load_addr should be used to get symbol address. My test shows symbol.addr.file_addr should be used, at least for types defined in exetuables, contrary to what’s documented. From: Greg Clayton<mailto:gclay...@apple.com> Sent: Monday, September 19, 2016 03:24 PM To: Lei Kong<mailto:leik...@msn.com> Subject: Re: [lldb-dev] OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t' You do want to be using the load address, it probably works because your file address matches your load address because you are probably working on your main executable, but this won't work for shared libraries. A few things: - you probably want to make sure a symbol matches your regex first before asking it for the vtable address. - not all symbols have addresses and asking for the file address or load address might return you lldb.LLDB_INVALID_ADDRESS. You should check for that before using the address in any way - you should use the load address of your symbol: def vtable_addr (symbol, target): load_addr = symbol.addr.GetLoadAddress(target) if load_addr != lldb.LLDB_INVALID_ADDRESS: return load_addr + 0x10 else: return lldb.LLDB_INVALID_ADDRESS The problem you were running into with overflow was probably because you were taking lldb.LLDB_INVALID_ADDRESS and adding 0x10, which would cause the integer to grow in size (http://stackoverflow.com/questions/2654149/count-bits-of-a-integer-in-python) and then not be able to be passed to the function that takes an lldb::addr_t. So diligently checking for lldb.LLDB_INVALID_ADDRESS will probably fix your problems. Also only try to compute the vtable stuff if the regex matches... Greg From: Greg Clayton<mailto:gclay...@apple.com> Sent: Monday, September 19, 2016 01:10 PM To: Lei Kong<mailto:leik...@msn.com> Cc: Jim Ingham<mailto:jing...@apple.com>; lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org> Subject: Re: [lldb-dev] OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t' > On Sep 19, 2016, at 1:09 PM, Greg Clayton wrote: > > >> On Sep 19, 2016, at 10:33 AM, Lei Kong wrote: >> >> You are right, it seems the argument is out of range, both vtableAddr and >> vtableAddr-8 are “8.5” byte long. Maybe there is something wrong with the >> way I get vtableAddress? I will clean up my full script and send it to you >> if the following does not provide enough information, thanks much. >> >> def vtable_addr (vtableSymbol): >>return vtableSymbol.addr.section.file_addr + vtableSymbol.addr.offset + >> 0x10 > > You actually want to get the load address when reading from memory. This > should be: > > def vtable_addr (vtableSymbol, target): >return vtableSymbol.addr.GetLoadAddress(target) + 0x10 If you actually wanted the file address of vtableSymbol's address, then you would do this: def vtable_addr (vtableSymbol, target): return vtableSymbol.addr.GetFileAddress() + 0x10 No need to do the section + offset math yourself. > >> >> >> vtableAddr, type=, value=0x1000f >> vtableAddr-8, type=, value=0x10007 >> Traceback (most recent call last): >> File "", line 1, in >> File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line >> 199, in findall >>findtypes(pattern,ignorePureVirtualType) >> File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line >> 156, in findtypes >>if ignorePureVirtualType and has_pure_virtual(vtableAddr, >> pureVirtualFuncs) : >> File "/home/leikong/repo/WindowsFabric/build.prod/test/fabdbg.py", line >> 100, in has_pure_virtual >>vtableEndAddr = lldb.process.ReadPointerFromMemory(vtableAddr-8, error) >> File "/home/leikong/bin/lldb/lib/python2.7/site-packages/lldb/__init__.py", >> line 9418, in ReadPointerFromMemory >>return _lldb.SBProcess_ReadPointerFromMemory(self, addr, error) >> OverflowError: in method 'SBProcess_ReadPointerFromMemory', argument 2 of >> type 'lldb::addr_t' >> >> From: Greg Clayton >> Sent: Monday, September 19, 2016 09:12 AM >> To: Lei Kong >> Cc: Jim Ingham; lldb-dev@lists.llvm.org >> Subject: Re: [lldb-dev] OverflowError: in method >> 'SBProcess_ReadPointerFromMemory', argument 2 of type 'lldb::addr_t' >> >> Try printing the type of the valu
