[lldb-dev] Passing as argument an array in a function call
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? I suspect the evaluator allocates the
memory for data and releases once the expression has been executed?
If so, can you please advise what's the proper way to achieve the same
functionality?
Thanks,
Dean
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 25847] "f s <#>" fails as short form for "frame select <#>"
https://llvm.org/bugs/show_bug.cgi?id=25847 Adrian McCarthy changed: What|Removed |Added Status|NEW |ASSIGNED CC||amcca...@google.com Assignee|lldb-dev@lists.llvm.org |amcca...@google.com --- Comment #3 from Adrian McCarthy --- I'll fix the message. I was looking at it anyway to make sure this wasn't a regression caused by my command handling refactor from several months ago. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Passing as argument an array in a function call
Looks like this is a MIPS specific bug, probably something we aren't handling
(relocation type maybe?) in the JITed code we produce:
This works fine on the MacOSX lldb:
(lldb) expr -- uint32_t data[6] = {}; test1(data); data
(uint32_t [6]) $0 = ([0] = 0x002a, [1] = 0x002b, [2] = 0x002c, [3]
= 0x002d, [4] = 0x002e, [5] = 0x002f)
> On Dec 16, 2015, at 6:06 AM, Dean De Leo via lldb-dev
> 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? I suspect the evaluator allocates the
> memory for data and releases once the expression has been executed?
>
> If so, can you please advise what's the proper way to achieve the same
> functionality?
>
>
> Thanks,
> Dean
> ___
> 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
Re: [lldb-dev] Passing as argument an array in a function call
> On Dec 16, 2015, at 6:06 AM, Dean De Leo via lldb-dev
> 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
Re: [lldb-dev] Passing as argument an array in a function call
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
Re: [lldb-dev] test rerun phase is in
Hmm okay I've now seen this on internal CI at least once when a rerun occurred. I'm going to switch the rerun to work with the multithreaded test runner with a single worker. Right now it is using the serial test runner, which I don't think gets nearly as much testing as the others and might be the root cause here. On Tue, Dec 15, 2015 at 6:37 PM, Todd Fiala wrote: > I see that build #4314 no longer hanged on aarch64. (It failed, but for > what looks like legitimate reasons). > > I'll make the change for arm as well. > > -Todd > > On Tue, Dec 15, 2015 at 5:14 PM, Todd Fiala wrote: > >> Arg okay. >> >> I restarted the aarch64 builder so that it will pick up my suppression >> there. >> >> I'll adjust it to suppress for arm as well, I'll have to hit that in >> about an hour or so but I will do it tonight. >> >> -Todd >> >> On Tue, Dec 15, 2015 at 4:00 PM, Ying Chen wrote: >> >>> It also happened for -A arm. >>> >>> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-android/builds/4307/steps/test7/logs/stdio >>> >>> On Tue, Dec 15, 2015 at 3:46 PM, Todd Fiala >>> wrote: >>> Hey Ying, I'm going to check in something that stops the rerun logic when both (1) -A aarch64 is specified and (2) --rerun-all-issues is not specified. That'll give me some time to drill into what's getting stuck on the android buildbot. -Todd On Tue, Dec 15, 2015 at 3:36 PM, Todd Fiala wrote: > #4310 failed for some other reason. > > #4311 looks like it might be stuck in the test3 phase but it is > showing less output than it had before (maybe because it hasn't timed out > yet). > > I'm usually running with --rerun-all-issues, but I can force similar > failures to what this bot is seeing when I crank up the load over there on > an OS X box. I'm doing that now and I'm omitting the --rerun-all-issues > flag, which should be close to how the android testbot is running. > Hopefully I can force it to fail here. > > If not, I'll temporarily disable the rerun unless --rerun-all-issues > until we can figure out what's causing the stall. > > BTW - how many cores are present on that box? That will help me > figure out which runner is being used for the main phase. > > Thanks! > > -Todd > > On Tue, Dec 15, 2015 at 2:34 PM, Todd Fiala > wrote: > >> Build >= #4310 is what I'll be watching. >> >> >> On Tue, Dec 15, 2015 at 2:30 PM, Todd Fiala >> wrote: >> >>> Okay cool. Will do. >>> >>> On Tue, Dec 15, 2015 at 2:22 PM, Ying Chen >>> wrote: >>> Sure. Please go ahead to do that. BTW, the pending builds should be merged into one build once current build is done. On Tue, Dec 15, 2015 at 2:12 PM, Todd Fiala wrote: > Hey Ying, > > Do you mind if we clear the android builder queue to get a build > with r255676 in it? There are what looks like at least 3 or 4 builds > between now and then, and with timeouts it may take several hours. > > -Todd > > On Tue, Dec 15, 2015 at 1:50 PM, Ying Chen > wrote: > >> Yes, it happens every time for android builder. >> >> On Tue, Dec 15, 2015 at 1:45 PM, Todd Fiala > > wrote: >> >>> Hmm, yeah it looks like it did the rerun and then after >>> finishing the rerun, it's just hanging. >>> >>> Let's have a look right after r255676 goes through this >>> builder. I hit a hang in the curses output display due to the >>> recursive >>> taking of a lock on a lock that was not recursive-enabled. While I >>> would >>> have expected to see that with the basic results output that this >>> builder >>> here is using when I was testing earlier, it's possible somehow >>> that we're >>> hitting a path here that is attempting to recursively take a lock. >>> >>> Do you know if it is happening every single time a rerun occurs? >>> (Hopefully yes?) >>> >>> -Todd >>> >>> On Tue, Dec 15, 2015 at 1:38 PM, Todd Fiala < >>> todd.fi...@gmail.com> wrote: >>> Yep, I'll have a look! On Tue, Dec 15, 2015 at 12:43 PM, Ying Chen wrote: > Hi Todd, > > It is noticed on lldb android builders that the test_runner > didn't exit after rerun, which caused buildbot timeout since the > process > was hanging for over 20 minutes. > Could you please take a look if that's related to your change? > > Please see the following builds. > > http://lab.llvm.org:8011/builders/lldb-x86_64-u
