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

[Dean De Leo via lldb-dev]

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