Another weird behavior with arm gcc 5.3

Discussion:

fengwei.yin

2016-04-06 14:53:34 UTC

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

Christophe Lyon

2016-04-06 15:11:01 UTC

Permalink

Post by fengwei.yin
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?

Post by fengwei.yin
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

Post by fengwei.yin
Suggestions/hints are welcome. Thanks a lot.
Regards
Yin, Fengwei
_______________________________________________
linaro-toolchain mailing list
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Jim Wilson

2016-04-06 16:13:07 UTC

Permalink

On Wed, Apr 6, 2016 at 8:11 AM, Christophe Lyon

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

Jim Wilson

2016-04-06 18:39:45 UTC

Permalink

Post by Jim Wilson
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

fengwei.yin

2016-04-07 13:25:38 UTC

Permalink

Hi Jim,

Post by Jim Wilson

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

Post by Jim Wilson
Jim

fengwei.yin

2016-04-07 03:44:28 UTC

Permalink

Post by Christophe Lyon

Post by fengwei.yin
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?

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

Post by Christophe Lyon
Thanks

Christophe Lyon

2016-04-07 12:14:10 UTC

Permalink

Post by fengwei.yin

Post by Christophe Lyon

Post by fengwei.yin
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?

Post by fengwei.yin
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).

Post by fengwei.yin
Regards
Yin, Fengwei

Post by Christophe Lyon
Thanks

fengwei.yin

2016-04-07 13:19:20 UTC

Permalink

Hi Christophe,

Post by Christophe Lyon

Post by fengwei.yin

Post by Christophe Lyon

Post by fengwei.yin
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?

Post by fengwei.yin
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

Post by Christophe Lyon

Post by fengwei.yin
Regards
Yin, Fengwei

Post by Christophe Lyon
Thanks