AArch64: Fix C++ mangling of va_list & apply ltsmaster's IndirectByvalRewrite fix #2813
Conversation
|
There's an ABI fix wrt. ExplicitByvalRewrite in ltsmaster which isn't in master yet... |
|
But a va_copy limitation which isn't in master... argh. |
kinke
changed the title
|
This pull gets ldc master to be able to bootstrap itself on Android/AArch64, fixing the link error I mentioned in #2811 yesterday. You may want to add the stdlib/dmd tests and that self-bootstrap to Shippable in this pull to make sure it doesn't regress. |
| hfaToArray.applyTo(arg, arg.ltype); | ||
| } else { | ||
| if (isReturnVal) { | ||
| integerRewrite.applyTo(arg); |
There was a problem hiding this comment.
ltsmaster doesn't use the IntegerRewrite at all; it uses CompositeToArray64 for rewriting returned structs (those not returned via sret). That casts the struct's address to [N x i64]* and loads from it, so if the struct is smaller than 8 bytes (or its size not a multiple of 8), this might be an issue (for args too, not just the return value). IntegerRewrite only works for power-of-2 sizes IIRC, so that's probably not really robust either.
kinke
changed the title
|
The |
|
Yay, now really fully buildable with latest ltsmaster. And less than 9 minutes for building the unittest runners is pretty impressive. |
|
The tests hang at some point, independent from ltsmaster/self host compiler, and apparently during the Phobos unittests as well as during dmd-testsuite. |
|
I can confirm that ldc master still bootstraps itself and passes the same tests on linux and Android/AArch64 with this pull. The segfault in the tests for |
kinke
changed the title
|
Not sure what to make of the output for various DMD tests (apparently not gdb related as the first Google results would suggest). |
|
Probably related to the unoptimized codegen issues I mentioned in #2153: I just tried it and can reproduce many segfaults and hangs with |
|
Looking good, once I get that druntime commit in, pretty much all the druntime tests should pass too. When do you plan to tag the 1.11 release and start building the compiler binaries? I'd like to get your suggested method of initializing TLS data on Android in for 1.11, ie replacing the delimiter symbols with parsing the ELF headers, but I'll have to get the path of the ELF file differently for shared libraries, which is how Android GUI apps (apks) are distributed, versus command-line binaries, which is easier and seems to be working in my experiments so far. |
This weekend (basically just waiting for this to be merged). 1.11 has been ready from my side for weeks, and now additionally got somewhat improved for AArch64 at the very last moment. I guess we'll have a 1.12 beta in a few weeks, so if you don't manage with the Android TLS stuff in those few days, that's fine too IMO. |
|
No, a couple days is plenty of time, should be able to get that in. |
C++ va_list is mangled as `std::__va_list` struct. According to clang IR, it's special in the sense of not ever being passed by value. Let's do the same and pass a pointer while at the same time mangling the function as taking the arg by value.
Some of those make the whole test run hang.
|
Looking into the Android TLS setup, but thought of a different way to do it than just calling functions from |
C++ va_list is mangled as
std::__va_liststruct. According to clang IR, it's special in the sense of not ever being passed by value.Let's do the same and pass a pointer while at the same time mangling the function as taking the arg by value.