This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
problem with gprof and 64bit build on solaris 10, amd/intel.
- From: James Coleman <jamesc at dspsrv dot com>
- To: binutils at sourceware dot org
- Date: Wed, 17 Oct 2007 15:06:25 +0100
- Subject: problem with gprof and 64bit build on solaris 10, amd/intel.
- Organisation: Hi waider! :)
- Watashi: wa sakana desu
Problem with gprof, 64bit build, solaris 10, amd/intel. Build flags: -m64 -pg
32bit builds with gprof are okay, non-gprof 64 bit builds are okay
Does gprof on solaris 64bit amd/intel work?
Has anyone encountered an error like this: "Error: junk `@' after expression" ?
Thanks,
James.
With most code compile fails with many messages like this:
/var/tmp//ccf6pGGR.s: Assembler messages:
/var/tmp//ccf6pGGR.s:32420: Error: junk `@' after expression
/var/tmp//ccf6pGGR.s:32459: Error: junk `@' after expression
/var/tmp//ccf6pGGR.s:32484: Error: junk `@' after expression
one of the offending lines is the leaq, line 32420 here:
32417 .LP1407:
32418 .quad 0
32419 .section .gnu.linkonce.t._ZN5boost6detail15sp_counted_base7destroyEv
32420 leaq .LP1407@(%rip),%r11
32421 call *_mcount@GOTPCREL(%rip)
32422 .loc 337 126 0
32423 testq %rdi, %rdi
Reducing to a simple example is interesting.
Doesn't reproduce above message but maybe this is or should be a known issue?
$ cat main.c
int main(void)
{
return 0;
}
$ g++ -c -m64 -pg main.c
$ g++ -o test -m64 -pg main.o
$ ./test
This seg-faults immediately, at this point seems to have memory size of 3.9G! but 50M or so rss.
It then seems get stuck dumping core and uses more and more memory.
I'm too impatient to see if it will exit before using all memory on machine.
$ pstack core
core 'core' of 12371: ./test
0000000000400f7b monstartup () + 1bf
pstack: warning: librtld_db failed to initialize; symbols from shared libraries will not be available
I tried with two sets of build tools:
gcc 3.4.3 with binutils 2.15 and solaris linker
gcc 4.1.1 with binutils 2.17 and solaris linker
$ ldd test
libstdc++.so.6 => /usr/sfw/lib/amd64/libstdc++.so.6
libm.so.2 => /lib/64/libm.so.2
libgcc_s.so.1 => /usr/sfw/lib/amd64/libgcc_s.so.1
libdl.so.1 => /lib/64/libdl.so.1
libc.so.1 => /lib/64/libc.so.1
Details for gcc 3.4.3 with binutils 2.15:
$ which g++
/usr/sfw/bin/g++
`which g++` --version
g++ (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
$ `which g++` -print-prog-name=ld
/usr/ccs/bin/ld
$ `which g++` -print-prog-name=as
/usr/sfw/bin/gas
$ /usr/ccs/bin/ld -V
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.482
$ /usr/sfw/bin/gas --version
GNU assembler 2.15
This assembler was configured for a target of `i386-pc-solaris2.10'.
Has the toolchain we are using been put together badly (for solaris intel/amd 64) I wonder?
We do compile a large amount of complex core for solaris intel/amd 64 and don't have
problems with that.
I believe the solaris linker is the one recommended for use on sparc but I wouldn't have
thought that would be true for the amd/intel platform?
Trying gnu linker directly?
$ /usr/sfw/i386-sun-solaris2.10/bin/ld -melf_x86_64 mainpg.o /usr/lib/64/crt1.o -o testgld
-L/lib/64 -L/usr/sfw/lib/64 -lgcc_s_amd64 -lstdc++ -lm -lc
$ ./testgld
testgld: Cannot find /lib/ld64.so.1
Killed
? ld64.so ?