> On Dec 16, 2015, at 6:06 AM, Dean De Leo via lldb-dev
> <lldb-dev@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".
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
