Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
On 7/4/2014 12:08 AM, Hans-Peter Nilsson wrote: Currently, c-cppbuiltin.c doesn't provide proper defines for this support. > >We > >currently define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, etc, in > >pa-linux.h. I thought that was cheating! 1/2:) > I'll experiment with defining ATOMIC_INT_LOCK_FREE there. > >It should already be defined, Yes, if the proper insn patterns are in place, those macros are automatically defined. They aren't if library functions are called, regardless of lock-freelessness of those functions. That is the problem. I added the __GCC_HAVE_SYNC_COMPARE_AND_SWAP defines when I saw that the library implementation was being detected by some packages. Trying an even bigger cheat: #define HAVE_sync_compare_and_swapqi 1 #define HAVE_sync_compare_and_swaphi 1 #define HAVE_sync_compare_and_swapsi 1 This seems to give __GCC_ATOMIC_INT_LOCK_FREE = 2, etc. Have to see if this works with our library functions :- Dave -- John David Anglindave.ang...@bell.net
Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
On Tue, 1 Jul 2014, Jonathan Wakely wrote: > On 1 July 2014 20:58, John David Anglin wrote: > > On 1-Jul-14, at 5:32 AM, Jonathan Wakely wrote: > > > >> On 1 July 2014 09:40, Matthias Klose wrote: > >>> > >>> - HPPA (build log [2]), is missing all the future_base symbols and > >>> exception_ptr13exception symbols, current_exception and > >>> rethrow_exception. Apparently the cheat mentioned below didn't fully work. :) > >> This implies ATOMIC_INT_LOCK_FREE <= 1 for that target. Our future and > >> exception_ptr implementations rely on usable atomics. > > > > > > ARM and HPPA use kernel assisted libraries for atomic support. Not exactly > > lock free, but possibly good enough... > > > > Currently, c-cppbuiltin.c doesn't provide proper defines for this support. > > We > > currently define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, etc, in > > pa-linux.h. I thought that was cheating! 1/2 :) > I'll experiment with defining ATOMIC_INT_LOCK_FREE there. > > It should already be defined, Yes, if the proper insn patterns are in place, those macros are automatically defined. They aren't if library functions are called, regardless of lock-freelessness of those functions. brgds, H-P
Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
On 01/07/14 09:40, Matthias Klose wrote: on some linux architectures there are some symbols missing in libstdc++.so.6 built from the 4.9 branch. I didn't notice before due to a packaging bug. affected are ARM32, HPPA, SPARC. - ARM32 (build log [1], both soft and hard float) are missing __aeabi_atexit@CXXABI_ARM_1.3.3 __aeabi_vec_* Can these be ignored? __aeabi_atexit is the function to be used instead of __cxa_atexit for the arm-none-linux-gnueabi(hf) targets as well as arm-none-eabi. Grokking around libstdc++-v3 I would have expected config/os/gnu-linux/arm-eabi-extra.ver to have added these symbols in and I'm not sure what's going on here. So prima-facie this is a bug. I wonder if something's broken in the handling of port_specific_symbol_files for arm. regards Ramana - HPPA (build log [2]), is missing all the future_base symbols and exception_ptr13exception symbols, current_exception and rethrow_exception. - SPARC (build log [3]) configured for sparc64-linux-gnu is missing symbols in the 32bit multilib build, although these are present in a sparc-linux-gnu build. Missing are same ones as in the HPPA build, long double 128 related symbols, numeric_limits, and some math symbols. Looks like more than one issue is involved, I remember that the math symbols were already dropped in earlier versions for other architectures. The build is configured -with-long-double-128. Matthias [1] https://buildd.debian.org/status/fetch.php?pkg=gcc-4.9&arch=armhf&ver=4.9.0-8&stamp=1403809654 [2] http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.9&arch=hppa&ver=4.9.0-9&stamp=1404018503 [3] http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.9&arch=sparc64&ver=4.9.0-9&stamp=1404033854
Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
On 01/07/14 20:58, John David Anglin wrote: On 1-Jul-14, at 5:32 AM, Jonathan Wakely wrote: On 1 July 2014 09:40, Matthias Klose wrote: - HPPA (build log [2]), is missing all the future_base symbols and exception_ptr13exception symbols, current_exception and rethrow_exception. This implies ATOMIC_INT_LOCK_FREE <= 1 for that target. Our future and exception_ptr implementations rely on usable atomics. ARM and HPPA use kernel assisted libraries for atomic support. Not exactly lock free, but possibly good enough... Currently, c-cppbuiltin.c doesn't provide proper defines for this support. We currently define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, etc, in pa-linux.h. I'll experiment with defining ATOMIC_INT_LOCK_FREE there. We then need to do the same on ARM especially for older architectures that don't have these sync patterns. Ramana Thanks, Dave -- John David Anglin dave.ang...@bell.net
Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
On 1-Jul-14, at 4:40 AM, Matthias Klose wrote: Looks like more than one issue is involved, I remember that the math symbols were already dropped in earlier versions for other architectures. The build is configured -with-long-double-128. Long double is 64 bits on hppa-linux. Dave -- John David Anglin dave.ang...@bell.net
Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
On Tue, Jul 01, 2014 at 10:40:06AM +0200, Matthias Klose wrote: > on some linux architectures there are some symbols missing in libstdc++.so.6 > built from the 4.9 branch. I didn't notice before due to a packaging bug. > affected are ARM32, HPPA, SPARC. > > - ARM32 (build log [1], both soft and hard float) are missing > __aeabi_atexit@CXXABI_ARM_1.3.3 > __aeabi_vec_* > >Can these be ignored? > > - HPPA (build log [2]), is missing all the future_base symbols and >exception_ptr13exception symbols, current_exception and >rethrow_exception. > > - SPARC (build log [3]) configured for sparc64-linux-gnu is missing >symbols in the 32bit multilib build, although these are present >in a sparc-linux-gnu build. Missing are same ones as in the HPPA >build, long double 128 related symbols, numeric_limits, and some >math symbols. > >Looks like more than one issue is involved, I remember that the >math symbols were already dropped in earlier versions for other >architectures. The build is configured -with-long-double-128. > I think that for sparc long double issue, the problem is that -with-long-double-128 doesn't work as -mlong-double-64 is forced when -m32 is used. I sent a patch a few months ago [1], but it has some side effect and I never came to a better version. Any help on how to do that properly is welcome, and I can build test some patches if needed. [1] https://gcc.gnu.org/ml/gcc-patches/2013-12/msg00318.html -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
On 1 July 2014 20:58, John David Anglin wrote: > On 1-Jul-14, at 5:32 AM, Jonathan Wakely wrote: > >> On 1 July 2014 09:40, Matthias Klose wrote: >>> >>> - HPPA (build log [2]), is missing all the future_base symbols and >>> exception_ptr13exception symbols, current_exception and >>> rethrow_exception. >> >> >> This implies ATOMIC_INT_LOCK_FREE <= 1 for that target. Our future and >> exception_ptr implementations rely on usable atomics. > > > ARM and HPPA use kernel assisted libraries for atomic support. Not exactly > lock free, but possibly good enough... > > Currently, c-cppbuiltin.c doesn't provide proper defines for this support. > We > currently define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, etc, in > pa-linux.h. I'll experiment with defining ATOMIC_INT_LOCK_FREE there. It should already be defined, but its value is what matters for libstdc++'s purposes. To be honest I'm not sure if we really need the value to be greater than one, if it's equal to one that might work. We'd need to check though.
Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
On 1-Jul-14, at 5:32 AM, Jonathan Wakely wrote: On 1 July 2014 09:40, Matthias Klose wrote: - HPPA (build log [2]), is missing all the future_base symbols and exception_ptr13exception symbols, current_exception and rethrow_exception. This implies ATOMIC_INT_LOCK_FREE <= 1 for that target. Our future and exception_ptr implementations rely on usable atomics. ARM and HPPA use kernel assisted libraries for atomic support. Not exactly lock free, but possibly good enough... Currently, c-cppbuiltin.c doesn't provide proper defines for this support. We currently define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, etc, in pa-linux.h. I'll experiment with defining ATOMIC_INT_LOCK_FREE there. Thanks, Dave -- John David Anglin dave.ang...@bell.net
Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
Am 01.07.2014 11:32, schrieb Jonathan Wakely: > On 1 July 2014 09:40, Matthias Klose wrote: >> - HPPA (build log [2]), is missing all the future_base symbols and >>exception_ptr13exception symbols, current_exception and >>rethrow_exception. > > This implies ATOMIC_INT_LOCK_FREE <= 1 for that target. Our future and > exception_ptr implementations rely on usable atomics. thanks for the reminder. then the same missing symbols for sparc is a missing --with-cpu-32=ultrasparc. Matthias
Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
On 1 July 2014 09:40, Matthias Klose wrote: > - HPPA (build log [2]), is missing all the future_base symbols and >exception_ptr13exception symbols, current_exception and >rethrow_exception. This implies ATOMIC_INT_LOCK_FREE <= 1 for that target. Our future and exception_ptr implementations rely on usable atomics. I don't know about the other missing symbols.
Re: missing symbols
On 6/18/07, costin_c <[EMAIL PROTECTED]> wrote: On 6/18/07, costin_c <[EMAIL PROTECTED]> wrote: > In the following code, compiled with > g++ cls.cc -Wall -W -g3 -o cls > > why only only virtual functions f1, f2 and constructor is listed by nm. Because they are needed for the vtable. While f3 is declared as inline and not used so it is not outputed. Wierd assembler file, generated by "-S" parameter, include all information about test class methods: test,f1,f2,f3 Not really because that is what you get with -g3. Thanks, Andrew Pinski
Re: missing symbols
On 6/18/07, costin_c <[EMAIL PROTECTED]> wrote:
In the following code, compiled with
g++ cls.cc -Wall -W -g3 -o cls
why only only virtual functions f1, f2 and constructor is listed by nm.
Only debugging symbols for virtual functions are included in
executable output file ?
//cls.cc
#include
using namespace std;
class test
{
public:
int u;
test(int t){u=t;};
virtual void f1(){
cout <
Wierd assembler file, generated by "-S" parameter, include all
information about test class methods: test,f1,f2,f3
..
.string "test::test"
.long 0x5d40
.string "test::f2"
.long 0x5d70
.string "test::f3"
.long 0x5e4d
.string "test::f1"
.long 0x5e71
.string "main"
