Hello list,
If you build Android using gcc-linaro-4.5-2011.05 [1], you will encounter a problem that bootanimation shows endless. It results from the mis-optimization in libgui, which handles the operations in Android SensorManager.
To work around this problem, you can apply the following patch:
--- a/libs/gui/Android.mk +++ b/libs/gui/Android.mk @@ -18,6 +18,8 @@ LOCAL_SHARED_LIBRARIES := \
LOCAL_MODULE:= libgui
+LOCAL_CFLAGS += -O0 + ifeq ($(TARGET_SIMULATOR),true) LOCAL_LDLIBS += -lpthread endif
Then, replace /system/lib/libgui.so with the newer one. I didn't look into the details. But at least, Android is able to serve user interaction again.
Related bug: https://bugs.launchpad.net/linaro-android/+bug/787072
Sincerely, -jserv
[1] Prebuilt x86 toolchain for Android: http://people.linaro.org/~jserv/toolchain/
Hi Jim,
On Fri, May 27, 2011 at 1:06 PM, Jim Huang jim.huang@linaro.org wrote:
Hello list,
If you build Android using gcc-linaro-4.5-2011.05 [1], you will encounter a problem that bootanimation shows endless. It results from the mis-optimization in libgui, which handles the operations in Android SensorManager.
To work around this problem, you can apply the following patch:
--- a/libs/gui/Android.mk +++ b/libs/gui/Android.mk @@ -18,6 +18,8 @@ LOCAL_SHARED_LIBRARIES := \
LOCAL_MODULE:= libgui
+LOCAL_CFLAGS += -O0
in channel you said that -O1 is also working ... do we need O0 here?
one idea would be to make a list of all optimizations that come for O2 and then spin builds with adding one at a time ... in that way we can narrow down things. Not sure if that would be helpful for fixing the issue.
we definitly should file a bug against linaro-android project and then also add gcc-linaro project so it gets visibility of toolchain WG.
On Fri, May 27, 2011 at 11:20 PM, Alexander Sack asac@linaro.org wrote:
Hi Jim,
On Fri, May 27, 2011 at 1:06 PM, Jim Huang jim.huang@linaro.org wrote:
Hello list,
If you build Android using gcc-linaro-4.5-2011.05 [1], you will encounter a problem that bootanimation shows endless. It results from the mis-optimization in libgui, which handles the operations in Android SensorManager.
To work around this problem, you can apply the following patch:
--- a/libs/gui/Android.mk +++ b/libs/gui/Android.mk @@ -18,6 +18,8 @@ LOCAL_SHARED_LIBRARIES := \
LOCAL_MODULE:= libgui
+LOCAL_CFLAGS += -O0
in channel you said that -O1 is also working ... do we need O0 here?
one idea would be to make a list of all optimizations that come for O2 and then spin builds with adding one at a time ... in that way we can narrow down things. Not sure if that would be helpful for fixing the issue.
we definitly should file a bug against linaro-android project and then also add gcc-linaro project so it gets visibility of toolchain WG.
Hi guys. Yip, let's start doing this properly. Can I suggest the same as the Ubuntu relationship and methods? Basically:
* You find an issue * Log a bug on Launchpad against the component or, failing that, linaro-android * Figure out if it is a toolchain or package problem * Figure out if there is a work around such as changing the optimisation level
If it is a toolchain issue: * Feel free to do a work around in the package * Add the right tags so you can revert the workaround in the future * Mark the bug as affecting gcc-linaro * Provide sufficient information to reproduce the bug - preprocessed source would be great!
and we'll get on to it.
We'll need some help in setting up a test environment. Note that a lot of the triage work is on the distribution side (i.e. Android).
-- Michael
On Mon, May 30, 2011 at 1:44 AM, Michael Hope michael.hope@linaro.org wrote:
On Fri, May 27, 2011 at 11:20 PM, Alexander Sack asac@linaro.org wrote:
Hi Jim,
On Fri, May 27, 2011 at 1:06 PM, Jim Huang jim.huang@linaro.org wrote:
Hello list,
If you build Android using gcc-linaro-4.5-2011.05 [1], you will encounter a problem that bootanimation shows endless. It results from the mis-optimization in libgui, which handles the operations in Android SensorManager.
To work around this problem, you can apply the following patch:
--- a/libs/gui/Android.mk +++ b/libs/gui/Android.mk @@ -18,6 +18,8 @@ LOCAL_SHARED_LIBRARIES := \
LOCAL_MODULE:= libgui
+LOCAL_CFLAGS += -O0
in channel you said that -O1 is also working ... do we need O0 here?
one idea would be to make a list of all optimizations that come for O2 and then spin builds with adding one at a time ... in that way we can narrow down things. Not sure if that would be helpful for fixing the issue.
we definitly should file a bug against linaro-android project and then also add gcc-linaro project so it gets visibility of toolchain WG.
Hi guys. Yip, let's start doing this properly. Can I suggest the same as the Ubuntu relationship and methods? Basically:
* You find an issue * Log a bug on Launchpad against the component or, failing that, linaro-android * Figure out if it is a toolchain or package problem * Figure out if there is a work around such as changing the optimisation level
If it is a toolchain issue: * Feel free to do a work around in the package * Add the right tags so you can revert the workaround in the future * Mark the bug as affecting gcc-linaro * Provide sufficient information to reproduce the bug - preprocessed source would be great!
and we'll get on to it.
We'll need some help in setting up a test environment. Note that a lot of the triage work is on the distribution side (i.e. Android).
-- Michael
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
I just discovered, that if you play that, and reload offen, you will get an slow sistem let other people to analize
Jim,
Would you share your toolchain improvements with Michael and also file the bug you ran into? Michael, do you think it makes sense to create a new bp like:
linaro-android-gcc-linaro-4.5-2011.05
that we can file bugs against?
On 29 May 2011 17:44, Michael Hope michael.hope@linaro.org wrote:
On Fri, May 27, 2011 at 11:20 PM, Alexander Sack asac@linaro.org wrote:
Hi Jim,
On Fri, May 27, 2011 at 1:06 PM, Jim Huang jim.huang@linaro.org wrote:
Hello list,
If you build Android using gcc-linaro-4.5-2011.05 [1], you will encounter a problem that bootanimation shows endless. It results from the mis-optimization in libgui, which handles the operations in Android SensorManager.
To work around this problem, you can apply the following patch:
--- a/libs/gui/Android.mk +++ b/libs/gui/Android.mk @@ -18,6 +18,8 @@ LOCAL_SHARED_LIBRARIES := \
LOCAL_MODULE:= libgui
+LOCAL_CFLAGS += -O0
in channel you said that -O1 is also working ... do we need O0 here?
one idea would be to make a list of all optimizations that come for O2 and then spin builds with adding one at a time ... in that way we can narrow down things. Not sure if that would be helpful for fixing the issue.
we definitly should file a bug against linaro-android project and then also add gcc-linaro project so it gets visibility of toolchain WG.
Hi guys. Yip, let's start doing this properly. Can I suggest the same as the Ubuntu relationship and methods? Basically:
* You find an issue * Log a bug on Launchpad against the component or, failing that, linaro-android * Figure out if it is a toolchain or package problem * Figure out if there is a work around such as changing the optimisation level
If it is a toolchain issue: * Feel free to do a work around in the package * Add the right tags so you can revert the workaround in the future * Mark the bug as affecting gcc-linaro * Provide sufficient information to reproduce the bug - preprocessed source would be great!
and we'll get on to it.
We'll need some help in setting up a test environment. Note that a lot of the triage work is on the distribution side (i.e. Android).
-- Michael
On Mon, May 30, 2011 at 12:51 PM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
Jim,
Would you share your toolchain improvements with Michael and also file the bug you ran into? Michael, do you think it makes sense to create a new bp like:
linaro-android-gcc-linaro-4.5-2011.05
We have the blueprint: https://blueprints.launchpad.net/gcc-linaro/+spec/toolchain-in-android
which is linked off: https://blueprints.launchpad.net/linaro/+spec/tr-toolchain-in-distributions
Bugs should not be filed against blueprints, but should be marked as affecting linaro-android and also gcc-linaro.
-- Michael
Cool. Thanks for the clarification.
On 29 May 2011 20:32, Michael Hope michael.hope@linaro.org wrote:
On Mon, May 30, 2011 at 12:51 PM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
Jim,
Would you share your toolchain improvements with Michael and also file the bug you ran into? Michael, do you think it makes sense to create a new bp like:
linaro-android-gcc-linaro-4.5-2011.05
We have the blueprint: https://blueprints.launchpad.net/gcc-linaro/+spec/toolchain-in-android
which is linked off: https://blueprints.launchpad.net/linaro/+spec/tr-toolchain-in-distributions
Bugs should not be filed against blueprints, but should be marked as affecting linaro-android and also gcc-linaro.
-- Michael
On 05/27/2011 01:20 PM, Alexander Sack wrote:
Hi Jim,
On Fri, May 27, 2011 at 1:06 PM, Jim Huangjim.huang@linaro.org wrote:
Hello list,
If you build Android using gcc-linaro-4.5-2011.05 [1], you will encounter a problem that bootanimation shows endless. It results from the mis-optimization in libgui, which handles the operations in Android SensorManager.
To work around this problem, you can apply the following patch:
--- a/libs/gui/Android.mk +++ b/libs/gui/Android.mk @@ -18,6 +18,8 @@ LOCAL_SHARED_LIBRARIES := \
LOCAL_MODULE:= libgui
+LOCAL_CFLAGS += -O0
in channel you said that -O1 is also working ... do we need O0 here?
one idea would be to make a list of all optimizations that come for O2 and then spin builds with adding one at a time ... in that way we can narrow down things. Not sure if that would be helpful for fixing the issue.
Hi there,
I've got an android build system up and running and had a quick look into this. When using the gcc-linaro-4.5-2011.05-0 the bootanimation runs forever when compiling the libgui.so using -O[s|1|2]. For me it only works when disabling all optizations (-O0). So, I've started with -O0 and tried to bisect the various optimization switches but I didn't fail. Next I've started with -O1 and disabled all the optimizations but it didn't pass. So, this approach was a dead end. Then I realized that the build system employs some sort of a prelinker called apriori. Adding 'LOCAL_PRELINK_MODULE := false' to the makefile disables the prelink step. And the resulting ELF binary finally worked (tested with -O[s|1|2]). It would be good to understand the root cause of this because the workaround probably has drawbacks at run (load) time. Apriori gets two input files. The prelink-linux-arm.map which lists the start of the prelink addresses: libui.so 0xAB900000 # [~1M] libgui.so 0xAB800000 # [~1M] libskia.so 0xAB100000 # [~2M] and the libgui.so to be prelinked. I'd expect to see the resulting PhysAddr's somewhere nearby 0xAB800000 but this doesn't seem to be the case somehow. In order to exclude a miscompiled apriori, I've prelinked libgui using an apriori binary build with the prebuilt gcc44 - no difference. Therefore I don't think gcc is miscompiling but something went wrong whith the prelink step. But still - the android prelinking remains a mystery to me as I don't know what is supposed to be prelinked and what is actually failing. However, I think we are one step further.
Regards Ken
Ken,
Awesome results. Would you mind if I assign the BP to you for this? Also, it sounds like we have something that we could put into the build system.
As far as prelink, would you mind posting these issues to android-building@googlegroups.com?
-Zach
On 9 June 2011 11:08, Ken Werner ken.werner@linaro.org wrote:
On 05/27/2011 01:20 PM, Alexander Sack wrote:
Hi Jim,
On Fri, May 27, 2011 at 1:06 PM, Jim Huangjim.huang@linaro.org wrote:
Hello list,
If you build Android using gcc-linaro-4.5-2011.05 [1], you will encounter a problem that bootanimation shows endless. It results from the mis-optimization in libgui, which handles the operations in Android SensorManager.
To work around this problem, you can apply the following patch:
--- a/libs/gui/Android.mk +++ b/libs/gui/Android.mk @@ -18,6 +18,8 @@ LOCAL_SHARED_LIBRARIES := \
LOCAL_MODULE:= libgui
+LOCAL_CFLAGS += -O0
in channel you said that -O1 is also working ... do we need O0 here?
one idea would be to make a list of all optimizations that come for O2 and then spin builds with adding one at a time ... in that way we can narrow down things. Not sure if that would be helpful for fixing the issue.
Hi there,
I've got an android build system up and running and had a quick look into this. When using the gcc-linaro-4.5-2011.05-0 the bootanimation runs forever when compiling the libgui.so using -O[s|1|2]. For me it only works when disabling all optizations (-O0). So, I've started with -O0 and tried to bisect the various optimization switches but I didn't fail. Next I've started with -O1 and disabled all the optimizations but it didn't pass. So, this approach was a dead end. Then I realized that the build system employs some sort of a prelinker called apriori. Adding 'LOCAL_PRELINK_MODULE := false' to the makefile disables the prelink step. And the resulting ELF binary finally worked (tested with -O[s|1|2]). It would be good to understand the root cause of this because the workaround probably has drawbacks at run (load) time. Apriori gets two input files. The prelink-linux-arm.map which lists the start of the prelink addresses: libui.so 0xAB900000 # [~1M] libgui.so 0xAB800000 # [~1M] libskia.so 0xAB100000 # [~2M] and the libgui.so to be prelinked. I'd expect to see the resulting PhysAddr's somewhere nearby 0xAB800000 but this doesn't seem to be the case somehow. In order to exclude a miscompiled apriori, I've prelinked libgui using an apriori binary build with the prebuilt gcc44 - no difference. Therefore I don't think gcc is miscompiling but something went wrong whith the prelink step. But still - the android prelinking remains a mystery to me as I don't know what is supposed to be prelinked and what is actually failing. However, I think we are one step further.
Regards Ken
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 10 June 2011 00:08, Ken Werner ken.werner@linaro.org wrote:
Hi there,
I've got an android build system up and running and had a quick look into this. When using the gcc-linaro-4.5-2011.05-0 the bootanimation runs forever when compiling the libgui.so using -O[s|1|2]. For me it only works when disabling all optimizations (-O0). So, I've started with -O0 and tried to bisect the various optimization switches but I didn't fail. Next I've started with -O1 and disabled all the optimizations but it didn't pass. So, this approach was a dead end. Then I realized that the build system employs some sort of a prelinker called apriori. Adding 'LOCAL_PRELINK_MODULE := false' to the makefile disables the prelink step. And the resulting ELF binary finally worked (tested with -O[s|1|2]).
hi Ken,
Thanks for your progress in advance.
Disabling prelinking looks fine, and actually SensorService in "master" branch disables prelinking as well: http://android.git.kernel.org/?p=platform/frameworks/base.git%3Ba=blob%3Bf=s...
The library libsensorservice is highly related to SensorService, which is activated by SystemServer, an essential process to bring up Android framework functionality.
In directory frameworks/base/services, libsensorservice is the only library which is attributed as non-prelinked.
It would be good to understand the root cause of this because the workaround probably has drawbacks at run (load) time. Apriori gets two input files. The prelink-linux-arm.map which lists the start of the prelink addresses: libui.so 0xAB900000 # [~1M] libgui.so 0xAB800000 # [~1M] libskia.so 0xAB100000 # [~2M] and the libgui.so to be prelinked. I'd expect to see the resulting PhysAddr's somewhere nearby 0xAB800000 but this doesn't seem to be the case somehow. In order to exclude a miscompiled apriori, I've prelinked libgui using an apriori binary build with the prebuilt gcc44 - no difference. Therefore I don't think gcc is miscompiling but something went wrong whith the prelink step. But still - the android prelinking remains a mystery to me as I don't know what is supposed to be prelinked and what is actually failing. However, I think we are one step further.
So, can you verify the behavior difference between prelink maps as well?
Cheers, -jserv
Ken,
Would you get a patch together for Google? This looks like a good small fix for when they upgrade to 4.5. Before pushing would you make sure that the fix doesn't break the current Android build. This should generate some good discussion about the underlying prelink issue.
-Zach
On 9 June 2011 14:56, Jim Huang jim.huang@linaro.org wrote:
On 10 June 2011 00:08, Ken Werner ken.werner@linaro.org wrote:
Hi there,
I've got an android build system up and running and had a quick look into this. When using the gcc-linaro-4.5-2011.05-0 the bootanimation runs forever when compiling the libgui.so using -O[s|1|2]. For me it only works when disabling all optimizations (-O0). So, I've started with -O0 and tried to bisect the various optimization switches but I didn't fail. Next I've started with -O1 and disabled all the optimizations but it didn't pass. So, this approach was a dead end. Then I realized that the build system employs some sort of a prelinker called apriori. Adding 'LOCAL_PRELINK_MODULE := false' to the makefile disables the prelink step. And the resulting ELF binary finally worked (tested with -O[s|1|2]).
hi Ken,
Thanks for your progress in advance.
Disabling prelinking looks fine, and actually SensorService in "master" branch disables prelinking as well: http://android.git.kernel.org/?p=platform/frameworks/base.git%3Ba=blob%3Bf=s...
The library libsensorservice is highly related to SensorService, which is activated by SystemServer, an essential process to bring up Android framework functionality.
In directory frameworks/base/services, libsensorservice is the only library which is attributed as non-prelinked.
It would be good to understand the root cause of this because the workaround probably has drawbacks at run (load) time. Apriori gets two input files. The prelink-linux-arm.map which lists the start of the prelink addresses: libui.so 0xAB900000 # [~1M] libgui.so 0xAB800000 # [~1M] libskia.so 0xAB100000 # [~2M] and the libgui.so to be prelinked. I'd expect to see the resulting PhysAddr's somewhere nearby 0xAB800000 but this doesn't seem to be the case somehow. In order to exclude a miscompiled apriori, I've prelinked libgui using an apriori binary build with the prebuilt gcc44 - no difference. Therefore I don't think gcc is miscompiling but something went wrong whith the prelink step. But still - the android prelinking remains a mystery to me as I don't know what is supposed to be prelinked and what is actually failing. However, I think we are one step further.
So, can you verify the behavior difference between prelink maps as well?
Cheers, -jserv
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Mon, Jun 13, 2011 at 8:48 AM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
Ken,
Would you get a patch together for Google? This looks like a good small fix for when they upgrade to 4.5. Before pushing would you make sure that the fix doesn't break the current Android build. This should generate some good discussion about the underlying prelink issue.
Note that this is a work-around and not a fix and should be presented as such. I'm afraid I don't want Ken to fix the root problem as it's not an area we're working on.
-- Michael
What's the root problem? Is there anyone else who can sort it out?
On 12 June 2011 16:11, Michael Hope michael.hope@linaro.org wrote:
On Mon, Jun 13, 2011 at 8:48 AM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
Ken,
Would you get a patch together for Google? This looks like a good small fix for when they upgrade to 4.5. Before pushing would you make sure that the fix doesn't break the current Android build. This should generate some good discussion about the underlying prelink issue.
Note that this is a work-around and not a fix and should be presented as such. I'm afraid I don't want Ken to fix the root problem as it's not an area we're working on.
-- Michael
On Mon, Jun 13, 2011 at 9:20 AM, Zach Pfeffer zach.pfeffer@linaro.org wrote:
What's the root problem? Is there anyone else who can sort it out?
Ah, there's the rub :) It could be in the Android specific prelinker, GCC, or in the code itself. The Android toolchain time I have set aside is for helping the Android group integrate our current outputs, and not for doing the initial triage or for working on new toolchain related components.
We should talk about this with Kiko and co and figure out what's next.
-- Michael
-
Alexander Sack -
Anca Emanuel -
Jim Huang -
Ken Werner -
Michael Hope -
Zach Pfeffer