Hi list, I hit another weird problem after use gcc 5.3 (If I use gcc 4.9, there is no any issue) with android.
With arm gcc 5.3, the C++ apps crash in one class constructor call. And gdb shows some vtbl items of the class are not relocated.
With arm gcc 4.9, if set breakpoint in that constructor, we could see the vtbl items of the class are relocated.
And Yes. I know the android bionic loader take response to do relocation. But if it works with gcc 4.9, I suppose bionic loader work well (unless gcc 5.3 create some new situation not handled by it).
I attached the vtbl dump in gdb for gcc 5.3 and 4.9 both. We could see all valid entries in vtbl are relocated in 4.9 dump. But not all entries in vtbl are relocated in 5.3 dump (the address is not started with 0xf).
Suggestions/hints are welcome. Thanks a lot.
Regards Yin, Fengwei
On 6 April 2016 at 16:53, fengwei.yin fengwei.yin@linaro.org wrote:
Hi list, I hit another weird problem after use gcc 5.3 (If I use gcc 4.9, there is no any issue) with android.
Hi,
Maybe this kind of problem would be handled better via bugzilla?
With arm gcc 5.3, the C++ apps crash in one class constructor call. And gdb shows some vtbl items of the class are not relocated.
With arm gcc 4.9, if set breakpoint in that constructor, we could see the vtbl items of the class are relocated.
And Yes. I know the android bionic loader take response to do relocation. But if it works with gcc 4.9, I suppose bionic loader work well (unless gcc 5.3 create some new situation not handled by it).
I attached the vtbl dump in gdb for gcc 5.3 and 4.9 both. We could see all valid entries in vtbl are relocated in 4.9 dump. But not all entries in vtbl are relocated in 5.3 dump (the address is not started with 0xf).
Can you share the relocations corresponding to these dumps? (output of objdump -r for instance)
Thanks
Suggestions/hints are welcome. Thanks a lot.
Regards Yin, Fengwei
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
On Wed, Apr 6, 2016 at 8:11 AM, Christophe Lyon christophe.lyon@linaro.org wrote:
On 6 April 2016 at 16:53, fengwei.yin fengwei.yin@linaro.org wrote:
With arm gcc 5.3, the C++ apps crash in one class constructor call. And gdb shows some vtbl items of the class are not relocated.
With arm gcc 4.9, if set breakpoint in that constructor, we could see the vtbl items of the class are relocated.
gcc 5.x implements C++ 2011 by default. gcc 4.9.x implements C++ 2003 by default. There were some ABI changes required to implement C++ 2011. If the android loader has knowledge of the gcc C++ ABI, maybe it needs to be updated to understand the new C++ 2011 ABI. You could try forcing the old ABI to see if that solves the problem. https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
And/or try using the older language standard with -std=c++03 or -std=gnu++03 to see if maybe that helps.
Jim
On Wed, Apr 6, 2016 at 9:13 AM, Jim Wilson jim.wilson@linaro.org wrote:
gcc 5.x implements C++ 2011 by default. gcc 4.9.x implements C++ 2003 by default. There were some ABI changes required to implement C++ 2011. If the android loader has knowledge of the gcc C++ ABI, maybe it needs to be updated to understand the new C++ 2011 ABI. You could try forcing the old ABI to see if that solves the problem. https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
And/or try using the older language standard with -std=c++03 or -std=gnu++03 to see if maybe that helps.
I only got this partly right. In gcc-5.x, libstdc++ is using the new C++ 2011 ABI, but g++ is still defaulting to c++98. The new libstdc++ ABI has caused trouble for a few people, so it might be relevant.
Jim
Hi Jim,
On 2016/4/7 2:39, Jim Wilson wrote:
On Wed, Apr 6, 2016 at 9:13 AM, Jim Wilson jim.wilson@linaro.org wrote:
gcc 5.x implements C++ 2011 by default. gcc 4.9.x implements C++ 2003 by default. There were some ABI changes required to implement C++ 2011. If the android loader has knowledge of the gcc C++ ABI, maybe it needs to be updated to understand the new C++ 2011 ABI. You could try forcing the old ABI to see if that solves the problem. https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
And/or try using the older language standard with -std=c++03 or -std=gnu++03 to see if maybe that helps.
I only got this partly right. In gcc-5.x, libstdc++ is using the new C++ 2011 ABI, but g++ is still defaulting to c++98. The new libstdc++ ABI has caused trouble for a few people, so it might be relevant.
I checked the cmdline which are same for gcc 4.9 and gc 5.3. It's like: -mandroid -fno-short-enums -fno-exceptions -Wno-psabi -DMOZ_ENABLE_JS_DUMP -include /opt/work/acadine/toolchain-update/B2G-v2.5/gonk-misc/Unicode.h -I/opt/work/acadine/toolchain-update/B2G-v2.5/external/libcxx/include -D_USING_LIBCXX -march=armv7-a -mthumb -mfpu=vfp -mfloat-abi=softfp -mno-unaligned-access -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -std=gnu++0x -pipe -DNDEBUG -DTRIMMED -g -freorder-blocks -Os -fno-reorder-functions -funwind-tables
And a bug for gcc was created to track this issue: https://bugs.linaro.org/show_bug.cgi?id=2169
Regards Yin, Fengwei
Jim
On 2016/4/6 23:11, Christophe Lyon wrote:
On 6 April 2016 at 16:53, fengwei.yin fengwei.yin@linaro.org wrote:
Hi list, I hit another weird problem after use gcc 5.3 (If I use gcc 4.9, there is no any issue) with android.
Hi,
Maybe this kind of problem would be handled better via bugzilla?
With arm gcc 5.3, the C++ apps crash in one class constructor call. And gdb shows some vtbl items of the class are not relocated.
With arm gcc 4.9, if set breakpoint in that constructor, we could see the vtbl items of the class are relocated.
And Yes. I know the android bionic loader take response to do relocation. But if it works with gcc 4.9, I suppose bionic loader work well (unless gcc 5.3 create some new situation not handled by it).
I attached the vtbl dump in gdb for gcc 5.3 and 4.9 both. We could see all valid entries in vtbl are relocated in 4.9 dump. But not all entries in vtbl are relocated in 5.3 dump (the address is not started with 0xf).
Can you share the relocations corresponding to these dumps? (output of objdump -r for instance)
The objdump -r is empty. And I have output of objdump -R which is 14M size txt file and not suitable for email. How can I share it to you? Thanks.
Regards Yin, Fengwei
Thanks
Suggestions/hints are welcome. Thanks a lot.
Regards Yin, Fengwei
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
On 7 April 2016 at 05:44, fengwei.yin fengwei.yin@linaro.org wrote:
On 2016/4/6 23:11, Christophe Lyon wrote:
On 6 April 2016 at 16:53, fengwei.yin fengwei.yin@linaro.org wrote:
Hi list, I hit another weird problem after use gcc 5.3 (If I use gcc 4.9, there is no any issue) with android.
Hi,
Maybe this kind of problem would be handled better via bugzilla?
With arm gcc 5.3, the C++ apps crash in one class constructor call. And gdb shows some vtbl items of the class are not relocated.
With arm gcc 4.9, if set breakpoint in that constructor, we could see the vtbl items of the class are relocated.
And Yes. I know the android bionic loader take response to do relocation. But if it works with gcc 4.9, I suppose bionic loader work well (unless gcc 5.3 create some new situation not handled by it).
I attached the vtbl dump in gdb for gcc 5.3 and 4.9 both. We could see all valid entries in vtbl are relocated in 4.9 dump. But not all entries in vtbl are relocated in 5.3 dump (the address is not started with 0xf).
Can you share the relocations corresponding to these dumps? (output of objdump -r for instance)
The objdump -r is empty. And I have output of objdump -R which is 14M size txt file and not suitable for email. How can I share it to you? Thanks.
I suggest you create a bugzilla entry and attached it there (in compressed form).
Regards Yin, Fengwei
Thanks
Suggestions/hints are welcome. Thanks a lot.
Regards Yin, Fengwei
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Hi Christophe,
On 2016/4/7 20:14, Christophe Lyon wrote:
On 7 April 2016 at 05:44, fengwei.yin fengwei.yin@linaro.org wrote:
On 2016/4/6 23:11, Christophe Lyon wrote:
On 6 April 2016 at 16:53, fengwei.yin fengwei.yin@linaro.org wrote:
Hi list, I hit another weird problem after use gcc 5.3 (If I use gcc 4.9, there is no any issue) with android.
Hi,
Maybe this kind of problem would be handled better via bugzilla?
With arm gcc 5.3, the C++ apps crash in one class constructor call. And gdb shows some vtbl items of the class are not relocated.
With arm gcc 4.9, if set breakpoint in that constructor, we could see the vtbl items of the class are relocated.
And Yes. I know the android bionic loader take response to do relocation. But if it works with gcc 4.9, I suppose bionic loader work well (unless gcc 5.3 create some new situation not handled by it).
I attached the vtbl dump in gdb for gcc 5.3 and 4.9 both. We could see all valid entries in vtbl are relocated in 4.9 dump. But not all entries in vtbl are relocated in 5.3 dump (the address is not started with 0xf).
Can you share the relocations corresponding to these dumps? (output of objdump -r for instance)
The objdump -r is empty. And I have output of objdump -R which is 14M size txt file and not suitable for email. How can I share it to you? Thanks.
I suggest you create a bugzilla entry and attached it there (in compressed form).
Yes. I am trying to create the bugzilla entry and will attach the -R dump. Thanks a lot for the suggestion.
Regards Yin, Fengwei
Regards Yin, Fengwei
Thanks
Suggestions/hints are welcome. Thanks a lot.
Regards Yin, Fengwei
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
linaro-toolchain@lists.linaro.org
-
Christophe Lyon -
fengwei.yin -
Jim Wilson