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 th
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
> 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
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] = 0x0
https://llvm.org/bugs/show_bug.cgi?id=25847
Adrian McCarthy changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
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}. Ho
