[lldb-dev] Frame documentation

[Greg Clayton]

> On Dec 4, 2014, at 4:17 PM, Jose H <jose.francisco.hevia at gmail.com> wrote:
> 
> Another thing is that I need to access big amounts of memory at the same time.
> 
> The intended use of this program is for accessing 5.000, 10.000, a
> million elements at the same time, for displaying it in a graph, for
> creating a difference graph, or for showing a little image. That kind
> of things.
> 
> So accessing just one element at a time using a function for each
> children element of an array is very inconvenient and inefficient.

Not to mention if you have:


uint32_t ints[10000000];

If you read the memory for "ints" you will need to read "10000000 * sizeof(uint32_t)" bytes. If you start accessing children by expanding "ints" you will get:

ints[0]
ints[1]
...
ints[9999999]

You don't want to read the bytes for any children of "ints" because they will just duplicate what you read for "ints". So you can either skip reading bytes for aggregate types (structs, unions, classes, arrays) and only read them for basic types (ints, floats, pointers, bools, etc).

> 
> So the ideal thing should be to access memory directly but with a
> mutex or something for avoiding conflict as the GUI lives on a thread,
> the debugger on another and (I suppose) the debugged process in
> another one.

What happens when your variable is in a register like rax? You can't assume all variables have addresses.

> 
> What is the best way to access memory of a process directly?

size_t
SBProcess::ReadMemory (addr_t addr, void *buf, size_t size, lldb::SBError &error);

Again, remember, not everything has an address. You can check with your SBValue by calling:

SBValue value = ...;

lldb::addr_t load_addr = value.GetLoadAddress();

if (load_addr != LLDB_INVALID_ADDRESS)
{
    // Item is in memory
}
else
{
    // Not in memory, or in memory but section isn't loaded (like global variable before or after running your process)
}