I verified and LLDB also works correctly in case of arm and aarch64 on
android (using lldb-server). My guess is that it is a MIPS specific but in
the SysV ABI but I haven't verified it.
Tamas
On Wed, Dec 16, 2015 at 6:37 PM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
>
> > 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
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
