The simplest way to accomplish this is to either cast the pointer to something:
(lldb) expr (Foo *)0x1230400000
Then you will be able to explore the expression result with the SBValue since
it will be a pointer to data in "Foo". If you don't have a "Foo" type you want
to cast to, you can make one yourself by creating a type with a '$' as the
first character (which makes the type globally available for future expressions:
(lldb) expr
struct $Foo {
uint32_t stuff[32];
};
return ($Foo *)0x1230400000
You will then be able to explore this. If you use a python command, you will be
able to run multiple expressions (the first to lookup the malloc_size(), then
second can use the result of the first to create the appropriate type with the
appropriate size as the result).
Greg
On Aug 23, 2013, at 5:08 PM, Sebastien Metrot <[email protected]> wrote:
> I used that and it works but I have to parse the result string. It's pretty
> simple but I always prefer to get the return value directly in the C++ API
> (in a SBValue/SBData kind of way).
> Wouldn't it be possible to have the malloc infos taken into account for
> SBValue that represent pointers so that we can enumerate the pointed data as
> children? Of course it could be somewhat wrong be cause the size we get from
> malloc_size is the block size and not the real size that was asked from
> malloc but it would probably still be better that having just one value.
>
> S.
>
> On 23 Aug 2013, at 02:31 , Greg Clayton <[email protected]> wrote:
>
>> Calling a function is easy:
>>
>> (lldb) expr (size_t)malloc_size(my_ptr)
>>
>> Your pointer might have to be the exact allocated address, it can't be just
>> any address in a heap allocated block.
>>
>> LLDB also has utilities that help you with heap stuff:
>>
>> (lldb) script import lldb.macosx
>> (lldb) malloc_info my_ptr
>>
>> Or if you want to find a pointer value inside memory:
>>
>> (lldb) ptr_prefs my_ptr
>>
>> If LLDB can determine the dynamic type of a block of memory, it might be
>> able to print it for you:
>>
>>
>> (lldb) malloc_info --type my_ptr
>>
>> IF the block is Objective C, you can PO the address of the containing block:
>>
>> (lldb) malloc_info --po my_ptr
>>
>>
>> For all the gory details type "help malloc_info" and "help ptr_refs" for
>> more information.
>>
>> Greg
>>
>>
>> On Aug 22, 2013, at 5:13 PM, Sebastien Metrot <[email protected]> wrote:
>>
>>> Hello,
>>>
>>> I'm trying to find a way to guess the size of data that was malloc'd in the
>>> debugged process. I know there is an unsupported malloc_size function on
>>> MacOSX that is equivalent to _msize on Win32 (not found the equivalent on
>>> linux yet) and I'm wondering what would be the best way to call these
>>> functions in the debugged process+address space in order to display the
>>> data that is pointed to as children of the pointer instead of a single
>>> value as of now.
>>>
>>> I though there was a way call a debuggee function with the lldb API but I
>>> haven't found it so I'm starting to think I have just imagined it.
>>>
>>> S.
>>> _______________________________________________
>>> lldb-dev mailing list
>>> [email protected]
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
