You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Android port is pretty stable now. It is stable enough to compile working Servo, for example. Let's enable tests on Android bot and start to block pull requests on it. We can reconsider if it is causing problems.
When the pull request is merged, make check-stage2-T-arm-linux-androideabi-H-x86_64-unknown-linux-gnu-rpass will pass. It takes about 5 minutes running on a hardware Android device.
Doesn't this involve having hardware with an arm processor on it? Right now I don't think that build artifacts are transferred between builders which is what it seems like this would have to do.
This would be awesome to be able to run tests on arm though, especially if it wasn't a huge slowdown on cycle time.
There is already an (admittedly hacky) necessary automation in place to transfer build artifacts to (and results from) an Android device using adb. It can be used with either a hardware Android device, or an Android emulator.
Unfortunately, this regressed, and currently all binaries result in segmentation fault on ARM. I bisected the problem down to #9301. Any idea what might be causing this?
That commit had to do with changing how the global crate map is passed around. It was no longer passed explicitly to main, but rather exposed as a weak symbol through various platform-defined methods. It perhaps means that the symbol/linker on arm does something a tad bit unusual, but it would probably warrant more investigation.
If the symbol returned NULL, then that'd kill all programs because one of the first things the runtime does is to set up logging.
@fhahn's work in #9593 will probably fix the segfault (but disabling logging), assuming that he implements @luqmana's suggestion to detect the crate map being null.
I tried a quick test by running a simple hello world (with some caveats as documented at #9632) with the android emulator and I can't reproduce a segfault.
I can reproduce the segfault with the Android emulator. I am not sure what's going on... Also, does anyone know how can one get a stack trace on Android?
My current hypothesis is that Android dynamic linker does something different for weak symbols. See this comment for example. I also confirmed that Android dynamic linker behaves differently from Linux dynamic linker with respect to weak symbols using a simple C code.
So 1. is this plausible, and 2. is it possible to avoid use of weak symbols? Thanks.
Does that mean that weak symbols don't work at all on android, or does that means that weak symbols just work differently on android?
If they don't work at all, we may have to re-think how we do this, but if they do work in some situations, then we can certainly have android-specific behavior.
Activity
sanxiyn commentedon Sep 11, 2013
When the pull request is merged,
make check-stage2-T-arm-linux-androideabi-H-x86_64-unknown-linux-gnu-rpass
will pass. It takes about 5 minutes running on a hardware Android device.alexcrichton commentedon Sep 12, 2013
Doesn't this involve having hardware with an arm processor on it? Right now I don't think that build artifacts are transferred between builders which is what it seems like this would have to do.
This would be awesome to be able to run tests on arm though, especially if it wasn't a huge slowdown on cycle time.
sanxiyn commentedon Sep 12, 2013
There is already an (admittedly hacky) necessary automation in place to transfer build artifacts to (and results from) an Android device using adb. It can be used with either a hardware Android device, or an Android emulator.
auto merge of #9121 : sanxiyn/rust/arm, r=alexcrichton
sanxiyn commentedon Sep 16, 2013
Pinging @brson.
brson commentedon Sep 17, 2013
We can't get this done before 0.8. Let's try afterward.
sanxiyn commentedon Sep 30, 2013
Unfortunately, this regressed, and currently all binaries result in segmentation fault on ARM. I bisected the problem down to #9301. Any idea what might be causing this?
alexcrichton commentedon Sep 30, 2013
That commit had to do with changing how the global crate map is passed around. It was no longer passed explicitly to main, but rather exposed as a weak symbol through various platform-defined methods. It perhaps means that the symbol/linker on arm does something a tad bit unusual, but it would probably warrant more investigation.
If the symbol returned NULL, then that'd kill all programs because one of the first things the runtime does is to set up logging.
huonw commentedon Sep 30, 2013
@fhahn's work in #9593 will probably fix the segfault (but disabling logging), assuming that he implements @luqmana's suggestion to detect the crate map being null.
luqmana commentedon Sep 30, 2013
I tried a quick test by running a simple hello world (with some caveats as documented at #9632) with the android emulator and I can't reproduce a segfault.
luqmana commentedon Sep 30, 2013
Logging seems to work fine too. @sanxiyn Could you get a stacktrace?
sanxiyn commentedon Oct 1, 2013
I can reproduce the segfault with the Android emulator. I am not sure what's going on... Also, does anyone know how can one get a stack trace on Android?
sanxiyn commentedon Oct 2, 2013
My current hypothesis is that Android dynamic linker does something different for weak symbols. See this comment for example. I also confirmed that Android dynamic linker behaves differently from Linux dynamic linker with respect to weak symbols using a simple C code.
So 1. is this plausible, and 2. is it possible to avoid use of weak symbols? Thanks.
alexcrichton commentedon Oct 2, 2013
Does that mean that weak symbols don't work at all on android, or does that means that weak symbols just work differently on android?
If they don't work at all, we may have to re-think how we do this, but if they do work in some situations, then we can certainly have android-specific behavior.
10 remaining items
auto merge of #10394 : yichoi/rust/make_check_pass_android, r=brson
sanxiyn commentedon Feb 4, 2014
This has been enabled. Closing.
https://mail.mozilla.org/pipermail/rust-dev/2014-January/008223.html
Auto merge of rust-lang#9120 - anall:bugfix/ice9041, r=Jarcho