Another weird behavior with arm gcc 5.3
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 (gdb) x/32xw 0xf6a1ed00 0xf6a1ed00 <_ZTVN7android12SortedVectorINS_16key_value_pair_tIiNS_2spINS_8AMessageEEE+32>: 0x004be99d 0x004bea1d 0x004bd9bf 0x 0xf6a1ed10 <_ZTVN7android15ARTSPConnectionE+4>: 0x 0x004be1c9 0x004be23d 0xf745d675 0xf6a1ed20 <_ZTVN7android15ARTSPConnectionE+20>:0xf745d675 0xf745f649 0xf745d675 0x004bf9c9 0xf6a1ed30 <_ZTVN7android18ARawAudioAssemblerE>:0x 0x 0x004bfc2d 0x004bfc59 0xf6a1ed40 <_ZTVN7android18ARawAudioAssemblerE+16>: 0xf745d675 0xf745d675 0xf745f649 0xf745d675 0xf6a1ed50 <_ZTVN7android18ARawAudioAssemblerE+32>: 0x004bfc6d 0x004bfddd 0x004bfb15 0x 0xf6a1ed60 <_ZTVN7android6VectorINS_11KeyedVectorINS_7AStringES2_+4>: 0x 0x004bfef1 0x004bff19 0x004c099d 0xf6a1ed70 <_ZTVN7android6VectorINS_11KeyedVectorINS_7AStringES2_+20>: 0x004bfea5 0x004bfebd 0x004bffa5 0x004bfde1 (gdb) 0xf6a1ed80 <_ZTVN7android6VectorINS_11KeyedVectorINS_7AStringES2_+36>: 0x004bfde1 0x 0x 0x004bff2d 0xf6a1ed90 <_ZTVN7android6VectorINS_7AStringEEE+12>:0x004bff55 0x004bfe8b 0x004bfe27 0x004bfded 0xf6a1eda0 <_ZTVN7android6VectorINS_7AStringEEE+28>:0x004bfe0b 0x004bfe3d 0x004bfe67 0x 0xf6a1edb0 <_ZTVN7android19ASessionDescriptionE+4>: 0x 0x004bff69 0x004bff91 0xf745d675 0xf6a1edc0 <_ZTVN7android19ASessionDescriptionE+20>:0xf745d675 0xf745f649 0xf745d675 0x 0xf6a1edd0 <_ZTVN7android21RtspConnectionHandlerE+4>: 0x 0x004c11c9 0x004c124d 0xf745d675 0xf6a1ede0 <_ZTVN7android21RtspConnectionHandlerE+20>: 0xf745d675 0xf745f649 0xf745d675 0x004c2981 0xf6a1edf0 <_ZTVN7android4ListINS_7AStringEEE>: 0x 0x 0x004c0a59 0x004c0a85 (gdb) info symbol 0xf745d675 android::RefBase::weakref_type::printRefs() const + 1 in section .text of symbols/system/lib/libutils.so (gdb) (gdb) x/32xw 0xf6ac1bfc 0xf6ac1bfc <_ZTVN7android15ARTSPConnectionE+4>: 0x 0xf430ce89 0xf430cf21 0xf7399705 0xf6ac1c0c <_ZTVN7android15ARTSPConnectionE+20>:0xf7399705 0xf739b651 0xf7399705 0xf430e6ad 0xf6ac1c1c: 0x 0x 0x 0xf430e94d 0xf6ac1c2c <_ZTVN7android18ARawAudioAssemblerE+12>: 0xf430e979 0xf7399705 0xf7399705 0xf739b651 0xf6ac1c3c <_ZTVN7android18ARawAudioAssemblerE+28>: 0xf7399705 0xf430e98d 0xf430eb01 0xf430e80d 0xf6ac1c4c: 0x 0x 0x 0xf430ebdd 0xf6ac1c5c <_ZTVN7android6VectorINS_11KeyedVectorINS_7AStringES2_+12>: 0xf430ebfd 0xf430ecd9 0xf430ebc7 0xf430ecad 0xf6ac1c6c <_ZTVN7android6VectorINS_11KeyedVectorINS_7AStringES2_+28>: 0xf430ec81 0xf430eb05 0xf430eb05 0x (gdb) 0xf6ac1c7c <_ZTVN7android6VectorINS_7AStringEEE+4>: 0x 0xf430ec11 0xf430ec31 0xf430ebaf 0xf6ac1c8c <_ZTVN7android6VectorINS_7AStringEEE+20>:0xf430eb4b 0xf430eb11 0xf430eb2f 0xf430eb61 0xf6ac1c9c <_ZTVN7android6VectorINS_7AStringEEE+36>:0xf430eb8b 0x 0x 0xf430ec45 0xf6ac1cac <_ZTVN7android19ASessionDescriptionE+12>:0xf430ec6d 0xf7399705 0xf7399705 0xf739b651 0xf6ac1cbc <_ZTVN7android19ASessionDescriptionE+28>:0xf7399705 0x 0x 0xf430fec1 0xf6ac1ccc <_ZTVN7android21RtspConnectionHandlerE+12>: 0xf430ff45 0xf7399705 0xf7399705 0xf739b651 0xf6ac1cdc <_ZTVN7android21RtspConnectionHandlerE+28>: 0xf7399705 0xf43116d5 0x 0x 0xf6ac1cec <_ZTVN7android4ListINS_7AStringEEE+4>: 0x 0xf430f769 0xf430f78d 0x___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Another weird behavior with arm gcc 5.3
On 6 April 2016 at 16:53, fengwei.yin 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 > ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Linaro toolchain: libstdc++.so: file format not recognized; treating as linker script
My dear friends,
I'm trying to build C++ code for Linux running on am ARM Cortex A8 (TI
AM335x). For a first try, I'm using the simplest program I can think of:
/* main.cpp */
int main() {
return 0;
}
Under Linux with the 'normal' GCC, that works fine, but under Windows 7
with the Linaro toolchain, it fails with the following message:
C:\firedect\dev\workspace\Test-Linux-ARM_1> "\Program Files (x86)\GNU
Tools ARM Embedded\gcc-linaro-4.9-2016.02-i686-ming
w32_arm-linux-gnueabi\bin\arm-linux-gnueabi-g++.exe" main.cpp
c:/program files (x86)/gnu tools arm
embedded/gcc-linaro-4.9-2016.02-i686-mingw32_arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.4/../../../../arm-linux-gnueabi/bin/ld.exe:c:/program
files (x86)/gnu tools arm
embedded/gcc-linaro-4.9-2016.02-i686-mingw32_arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.4/../../../../arm-linux-gnueabi/lib/libstdc++.so:
file format not recognized; treating as linker script
c:/program files (x86)/gnu tools arm
embedded/gcc-linaro-4.9-2016.02-i686-mingw32_arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.4/../../../../arm-linux-gnueabi/bin/ld.exe:c:/program
files (x86)/gnu tools arm
embedded/gcc-linaro-4.9-2016.02-i686-mingw32_arm-linux-gnueabi/bin/../lib/gcc/arm-linux-gnueabi/4.9.4/../../../../arm-linux-gnueabi/lib/libstdc++.so:1:
syntax error
collect2.exe: error: ld returned 1 exit status
C:\firedect\dev\workspace\Test-Linux-ARM_1> "\Program Files (x86)\GNU
Tools ARM Embedded\gcc-linaro-5.3-2016.02-i686-ming
w32_arm-linux-gnueabihf\bin\arm-linux-gnueabihf-g++.exe" main.cpp
c:/program files (x86)/gnu tools arm
embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/bin/ld.exe:c:/program
files (x86)/gnu tools arm
embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/lib/libstdc++.so:
file format not recognized; treating as linker script
c:/program files (x86)/gnu tools arm
embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/bin/ld.exe:c:/program
files (x86)/gnu tools arm
embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/lib/libstdc++.so:1:
syntax error
collect2.exe: error: ld returned 1 exit status
As you can see, I have tested two versions of the toolchain, which show
the same behavior.
Do you have any idea what's going wrong here? I'd appreciate any help
you can provide!
--
Kind regards,
Gunnar Arndt
smime.p7s
Description: S/MIME Cryptographic Signature
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Another weird behavior with arm gcc 5.3
On Wed, Apr 6, 2016 at 8:11 AM, Christophe Lyon wrote: > On 6 April 2016 at 16:53, fengwei.yin 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 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Another weird behavior with arm gcc 5.3
On Wed, Apr 6, 2016 at 9:13 AM, Jim Wilson 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 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Linaro toolchain: libstdc++.so: file format not recognized; treating as linker script
On Wed, Apr 6, 2016 at 8:15 AM, Gunnar Arndt wrote: > embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/lib/libstdc++.so: > file format not recognized; treating as linker script > c:/program files (x86)/gnu tools arm > embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/bin/ld.exe:c:/program > files (x86)/gnu tools arm > embedded/gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/5.3.1/../../../../arm-linux-gnueabihf/lib/libstdc++.so:1: > syntax error > collect2.exe: error: ld returned 1 exit status I get a slightly different error when I try this. I get the file format not recognized error, but then it quits instead of trying to read it as a linker script. The file in question is a symlink. If you use a cygwin tar binary to extract the tar.xz file on the windows machine, then cygwin by default creates cygwin style symlinks, which can only be understood by cygwin programs. The toolchain we released is not a cygwin binary, so it can't follow these symlinks, and you get the error. I see two ways to solve this problem. 1) In cygwin, you can do "export CYGWIN=winsymlinks" before extracting the tar.xz file. You will then get a windows short-cut instead of a cygwin style symlink, and the toolchain will work. https://cygwin.com/faq.html#faq.api.symlinks The faq mentions different ls output, but I didn't see that. I do see a difference in file explorer. The cygwin so symlink appears as type "SO File", where as the windows short-cut appears as type "Shortcut". 2) Use a non-cygwin program to extract the package. I don't know if there is a non-cygwin tar available, but you could extract on a linux machine, use zip to create a zip/pkzip archive, and then use a windows unzip/pkzip program to extract it. I didn't try this, but this should in theory work. Jim ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Another weird behavior with arm gcc 5.3
On 2016/4/6 23:11, Christophe Lyon wrote: On 6 April 2016 at 16:53, fengwei.yin 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 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain
