Hi,
it turned out to be due to a local change in my repository, where I've forced Process::CanJIT() to be always evaluated, to track down a different unrelated issue, instead of using m_can_jit. Restoring
the original semantic resolved my issue. I can now imagine that CanJIT() interfered with the memory already allocated in the device.
I am sorry for this oversight :/
Thanks,
Dean
On 16/12/15 19:29, Tamas Berghammer wrote:
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
<mailto: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
<mailto: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 <mailto: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
