This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

problem with gprof and 64bit build on solaris 10, amd/intel.



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 ?



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]