This is an archive of the discontinued LLVM Phabricator instance.

Add IR fixups for RenderScript ABI mismatch between ARMV7 frontend and x86 backend
ClosedPublic

Authored by ldrumm on Mar 10 2016, 11:45 AM.

Details

Summary

Expression evaluation for function calls to certain public RenderScript API functions in libRSCPURef can segfault.

[`slang`](https://android.googlesource.com/platform/frameworks/compile/slang),
the compiler frontend for RenderScript embeds an ARM specific triple in IR that is shipped in the app, after
generating IR that has some assumptions that an ARM device is the target.
As the IR is then compiled on a device of unknown (at time the IR was generated at least) architecture,
when calling RenderScript API function as part of debugger expressions, we have to perform a fixup pass that
removes those assumptions right before the module is sent to be generated by the llvm backend.

This issue is caused by multiple problems with the ARMv7-specific assumptions encoded in the LLVM IR. x86 large value returns use a hidden first argument (mapping to llvm::Attribute::StructRet), which can't be picked up by the JIT due to the mismatch between IR generated by the slang frontend and llvm backend. This means that code generated by bcc did not necessarily match the default SysV Linux/Android ABI used by the LLDB JIT

Diff Detail

Event Timeline

ldrumm updated this revision to Diff 50322.Mar 10 2016, 11:45 AM
ldrumm retitled this revision from to Add IR fixups for RenderScript ABI mismatch between ARMV7 frontend and x86 backend.
ldrumm updated this object.

I dont have a lot of background in this area of the code. Can you kindly take a look.

clayborg resigned from this revision.Mar 17 2016, 10:05 AM
clayborg edited reviewers, added: spyffe; removed: clayborg.

Sean Callanan would have more expertise in this area.

  1. List Item
ldrumm updated this revision to Diff 65927.Jul 28 2016, 7:14 AM
ldrumm edited edge metadata.
This revision was automatically updated to reflect the committed changes.
tfiala added a subscriber: tfiala.Jul 28 2016, 10:54 AM

I've got a fix to make this work in Xcode, but I'm currently stuck behind the missing Condition.cpp from r277011 to verify.

I've got a fix to make this work in Xcode, but I'm currently stuck behind the missing Condition.cpp from r277011 to verify.

Thanks Todd. I don't really deal with XCode, so that's a real help.

Regarding r277012, I'm a little confused about the message "Also, fixed up typos in RenderScript code that could not possibly compile." Is this code broken somehow? It build for us with GCC, and green dragon seems fine with it. Is there some particular compiler for which this is broken because everything "Works for Me"?

I've got a fix to make this work in Xcode, but I'm currently stuck behind the missing Condition.cpp from r277011 to verify.

Thanks Todd. I don't really deal with XCode, so that's a real help.

My pleasure! We expect to need to do this on the Xcode side since we aren't using cmake like everyone else.

Regarding r277012, I'm a little confused about the message "Also, fixed up typos in RenderScript code that could not possibly compile." Is this code broken somehow? It build for us with GCC, and green dragon seems fine with it. Is there some particular compiler for which this is broken because everything "Works for Me"?

Nope nope you're fine. I tried to quickly fix my comment in follow ups to my commit message emails. I looked too quickly at the filenames and figured the error was introduced from the RenderScript change. It was in fact from Saleem's change. It was in files that he couldn't compile unless he was on Xcode, so the typos came in there.

I've got a fix to make this work in Xcode, but I'm currently stuck behind the missing Condition.cpp from r277011 to verify.

Thanks Todd. I don't really deal with XCode, so that's a real help.

My pleasure! We expect to need to do this on the Xcode side since we aren't using cmake like everyone else.

Regarding r277012, I'm a little confused about the message "Also, fixed up typos in RenderScript code that could not possibly compile." Is this code broken somehow? It build for us with GCC, and green dragon seems fine with it. Is there some particular compiler for which this is broken because everything "Works for Me"?

Nope nope you're fine. I tried to quickly fix my comment in follow ups to my commit message emails. I looked too quickly at the filenames and figured the error was introduced from the RenderScript change. It was in fact from Saleem's change. It was in files that he couldn't compile unless he was on Xcode, so the typos came in there.

Ah! I see the email. Thanks for the clarification.

Best

Luke

Ah! I see the email. Thanks for the clarification.

Best

Luke

Sure thing :-) Sorry for the confusion.