[lldb-dev] Passing as argument an array in a function call

[Greg Clayton via lldb-dev]

> On Dec 16, 2015, at 6:06 AM, Dean De Leo via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> Hi,
> 
> assume we wish to use the expression evaluator to invoke a function from lldb, setting the result into an array passed as parameter, e.g:
> 
> void test1(uint32_t* d) {
>    for(int i = 0; i < 6; i++){
>        d[i] = 42 + i;
>    }
> }
> 
> where the expected output should be d = {42,43,44,45,46,47}. However performing the following expression having as target android/mips32 returns:
> 
> (lldb) expr -- uint32_t data[6] = {}; test1(data);  data
> (uint32_t [6]) $4 = ([0] = 0, [1] = 2003456944, [2] = 44, [3] = 45, [4] = 2004491136, [5] = 47)
> 
> Is this an expected behaviour or a bug?

Definitely a bug in LLDB somewhere, or possibly in the memory allocation on the MIPS host that is done via lldb-server. Are you using lldb-server here? It has an allocate memory packet.

> I suspect the evaluator allocates the memory for data and releases once the expression has been executed?

We allocate memory for the resulting data that continues to exist in your process so the memory shouldn't be released.

> If so, can you please advise what's the proper way to achieve the same functionality?

This should work so it will be a matter of tracking down what is actually failing. If you can run to where you want to run your expression and then before you run your expression do:

(lldb) log enable -f /tmp/log.txt gdb-remote packets
(lldb) log enable -f /tmp/log.txt lldb expr

Then run your expression and then do:

(lldb) log disable gdb-remote packets
(lldb) log disable lldb expr

Then send the file, we might be able to see what is going on. The GDB remote packets will allow us to see the memory that is allocated, and the "lldb expr" will allow us to see all of the gory details as to where it is trying to use "d".