Re: buildworld fails in gnu/usr.bin/gperf/doc with an internal error
On Sun, 22 Sep 2002 11:27:08 -0400 Alexander Kabaev [EMAIL PROTECTED] wrote: Alexander, can you get me a backtrace from the failed GCC process? What process it is, by the way? GCC, CC1, CPP1? I tried to workaround the problem by building the new gcc (cd /usr/src/gnu/usr.bin/cc; make), but I get this error: ---snip--- === cc_int Warning: Object directory not changed from original /big/usr/src/gnu/usr.bin/cc/cc_int cc -O -pipe -v -mcpu=pentiumpro -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\ -I/big/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/big/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/big/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/big/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -DHAVE_CONFIG_H -DTARGET_NAME=\i386-undermydesk-freebsd\ -DIN_GCC -c /big/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/c-format.c -o c-format.o Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.1 [FreeBSD] 20020509 (prerelease) /usr/libexec/cc1 -lang-c -v -I/big/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/big/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/big/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/big/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -D__GNUC__=3 -D__GNUC_MINOR__=1 -D__GNUC_PATCHLEVEL__=0 -D__FreeBSD__=5 -D__FreeBSD_cc_version=53 -Dunix -D__KPRINTF_ATTRIBUTE__ -D__FreeBSD__=5 -D__FreeBSD_cc_version=53 -D__unix__ -D__KPRINTF_ATTRIBUTE__ -D__unix -Asystem=unix -Asystem=bsd -Asystem=FreeBSD -D__OPTIMIZE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i686__ -D__tune_pentiumpro__ -D__ELF__ -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=/usr -DHAVE_CONFIG_H -DTARGET_NAME=i386-undermydesk-freebsd -DIN_GCC /big/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/c-format.c -quiet -dumpbase c-format.c -mcpu=pentiumpro -O -version -o - | /usr/libexec/elf/as -v -o c-format.o - GNU assembler version 2.12.0 [FreeBSD] 2002-04-10 (i386-obrien-freebsd5.0) using BFD version 2.12.0 [FreeBSD] 2002-04-10 GNU CPP version 3.1 [FreeBSD] 20020509 (prerelease) (cpplib) (i386 FreeBSD/ELF) GNU C version 3.1 [FreeBSD] 20020509 (prerelease) (i386-undermydesk-freebsd) compiled by GNU C version 3.1 [FreeBSD] 20020509 (prerelease). ignoring duplicate directory /big/usr/src/gnu/usr.bin/cc/cc_tools ignoring duplicate directory /usr/include #include ... search starts here: #include ... search starts here: /big/usr/src/gnu/usr.bin/cc/cc_tools /big/usr/src/contrib/gcc /big/usr/src/contrib/gcc/config /usr/include End of search list. ld: can't get PREFIX *** Error code 1 ---snip--- Any ideas? Bye, Alexander. -- I believe the technical term is Oops! http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld fails in gnu/usr.bin/gperf/doc with an internal error
On Fri, Sep 27, 2002 at 01:39:10PM +0200, Alexander Leidinger wrote: ignoring duplicate directory /big/usr/src/gnu/usr.bin/cc/cc_tools ignoring duplicate directory /usr/include #include ... search starts here: #include ... search starts here: /big/usr/src/gnu/usr.bin/cc/cc_tools /big/usr/src/contrib/gcc /big/usr/src/contrib/gcc/config /usr/include End of search list. ld: can't get PREFIX ~~ *** Error code 1 ---snip--- Any ideas? Sounds like the ld-wrapper of the icc port. Is your path-search-order bogus or did you kill the nativ ld ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld fails in gnu/usr.bin/gperf/doc with an internal error
On Fri, 27 Sep 2002 15:33:59 +0200 [EMAIL PROTECTED] wrote: ld: can't get PREFIX ~~ *** Error code 1 ---snip--- Any ideas? Sounds like the ld-wrapper of the icc port. Is your path-search-order bogus or did you kill the nativ ld ? Damn... yes. root still had source .../iccvars.sh. We should improve the error message in the ld wrapper for icc. Thanks, Alexander. -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld fails in gnu/usr.bin/gperf/doc with an internal error
On Sun, 22 Sep 2002 21:29:45 -0400 Craig Rodrigues [EMAIL PROTECTED] wrote: From there, you should be able to see what the backtrace is to where things are crashing. It crashes in cc1plus, but the backtrace isn't useful, as I don't have a debug version of cc1plus here (I don't get any symbols out if cc1plus, not with nm and not with objdump). gdb /usr/libexec/cc1plus [...] Program received signal SIGSEGV, Segmentation fault. 0x081ed6c3 in ?? () (gdb) bt #0 0x081ed6c3 in ?? () #1 0x081eddbb in ?? () #2 0x081ee612 in ?? () #3 0x08148033 in ?? () #4 0x0814c497 in ?? () #5 0x0814c4f8 in ?? () #6 0x0804c9db in ?? () #7 0x08048139 in ?? () The disassembly of #0 is (not that I think this may be helpful here): ---snip--- 81ed6ae: 89 74 24 04 mov%esi,0x4(%esp,1) 81ed6b2: e8 29 f8 ff ff call 0x81ecee0 81ed6b7: 8b 5d f8mov0xfff8(%ebp),%ebx 81ed6ba: 8b 75 fcmov0xfffc(%ebp),%esi 81ed6bd: c9 leave 81ed6be: c3 ret 81ed6bf: 90 nop 81ed6c0: 55 push %ebp 81ed6c1: 89 e5 mov%esp,%ebp 81ed6c3: 83 34 41 08 xorl $0x8,(%ecx,%eax,2) 81ed6c7: 07 pop%es 81ed6c8: 00 00 add%al,(%eax) 81ed6ca: 00 c7 add%al,%bh 81ed6cc: 05 1c 34 41 08 add$0x841341c,%eax 81ed6d1: 07 pop%es 81ed6d2: 00 00 add%al,(%eax) 81ed6d4: 00 a1 10 34 41 08 add%ah,0x8413410(%ecx) 81ed6da: a3 20 34 41 08 mov%eax,0x8413420 81ed6df: a1 53 08 89 d0 mov0xd0890853,%eax 81ed6e4: 83 e0 3fand$0x3f,%eax 81ed6e7: 83 c8 40or $0x40,%eax ---snip--- c++ -save-temps -v -O -I/big/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/big/usr/src/gnu/usr.bin/gperf -c /big/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/gen-perf.cc generates: http://www.leidinger.net/gen-perf.ii.bz2 http://www.leidinger.net/gen-perf.s.bz2 Bye, Alexander. -- The dark ages were caused by the Y1K problem. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld fails in gnu/usr.bin/gperf/doc with an internal error
On Sun, 22 Sep 2002 17:20:14 +0200 Alexander Leidinger [EMAIL PROTECTED] wrote: Alexander, can you get me a backtrace from the failed GCC process? What process it is, by the way? GCC, CC1, CPP1? -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld fails in gnu/usr.bin/gperf/doc with an internal error
On Sun, 22 Sep 2002 11:27:08 -0400 Alexander Kabaev
[EMAIL PROTECTED] wrote:
Alexander, can you get me a backtrace from the failed GCC process?
What process it is, by the way? GCC, CC1, CPP1?
This is with a gcc 3.1 world, the internal error is in stage 1:
bootstrap tools and gcc 3.2 isn't build at this point. Do you still
want the backtrace?
If yes: I can't find a *.core in /usr/{src,obj}, there's no coredump
limit, so how do I get the backtrace? I already tried to go into
gnu/usr.bin/gperf and make a make cleandir; make cleandir; make, but I
don't get a coredump.
I also tried to run it withhin gdb, but c++ exists with something like
exit(1) and thats it, no way to make a backtrace.
Bye,
Alexander.
--
Reboot America.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: buildworld fails in gnu/usr.bin/gperf/doc with an internal error
This is with a gcc 3.1 world, the internal error is in stage 1:
bootstrap tools and gcc 3.2 isn't build at this point. Do you still
want the backtrace?
Yes.
If yes: I can't find a *.core in /usr/{src,obj}, there's no coredump
limit, so how do I get the backtrace? I already tried to go into
gnu/usr.bin/gperf and make a make cleandir; make cleandir; make, but
I don't get a coredump.
I also tried to run it withhin gdb, but c++ exists with something like
exit(1) and thats it, no way to make a backtrace.
What does kernel log say? When process dies with signal, kernel usually
logs the event. If anything, this should give you the name of the
process which has died. Running 'gcc' or 'c++' under debugger is not
very helpful, because these are just driver programs. The real processes
which do the work are cpp1, cc1, ccp1 etc.
--
Alexander Kabaev
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: buildworld fails in gnu/usr.bin/gperf/doc with an internal error
On Sun, 22 Sep 2002 13:47:26 -0400 Alexander Kabaev
[EMAIL PROTECTED] wrote:
If yes: I can't find a *.core in /usr/{src,obj}, there's no coredump
limit, so how do I get the backtrace? I already tried to go into
gnu/usr.bin/gperf and make a make cleandir; make cleandir; make,
but I don't get a coredump.
I also tried to run it withhin gdb, but c++ exists with something
like exit(1) and thats it, no way to make a backtrace.
What does kernel log say? When process dies with signal, kernel
/var/log/messages and dmesg only tell me about
---snip---
0xc31a2814 bw 6868 rttbest 1062 srtt 1653 bwnd 5816
0xc31a2814 bw 6268 rttbest 1062 srtt 1647 bwnd 5556
0xc398235c bw 7746 rttbest 3417 srtt 6833 bwnd 15309
---snip---
there's nothing else.
usually logs the event. If anything, this should give you the name of
the process which has died. Running 'gcc' or 'c++' under debugger is
not very helpful, because these are just driver programs. The real
processes which do the work are cpp1, cc1, ccp1 etc.
What about a ktrace -i: http://www.leidinger.net/ktrace.out.bz2
(~50k), please tell me when you got it, I want to remove it then.
Bye,
Alexander.
--
There's no place like ~
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: buildworld fails in gnu/usr.bin/gperf/doc with an internal error
On Sun, Sep 22, 2002 at 08:10:38PM +0200, Alexander Leidinger wrote: What about a ktrace -i: http://www.leidinger.net/ktrace.out.bz2 (~50k), please tell me when you got it, I want to remove it then. What you want to do is, figure out exactly which program is crashing. Add -v to your gcc flags, eg. gcc -v -march=pentium-pro -c a.c This will show you which programs are being invoked by gcc, which do the actual compiling. For example, === Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.2.1 [FreeBSD] 20020901 (prerelease) /usr/libexec/cc1 -lang-c -v -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL __=1 -D__GXX_ABI_VERSION=102 -D__FreeBSD__=5 -D__FreeBSD_cc_version=53 -Duni x -D__KPRINTF_ATTRIBUTE__ -D__FreeBSD__=5 -D__FreeBSD_cc_version=53 -D__unix __ -D__KPRINTF_ATTRIBUTE__ -D__unix -Asystem=unix -Asystem=bsd -Asystem=FreeBSD -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D __i386__ -D__ELF__ a.c -quiet -dumpbase a.c -march=pentium-pro -version -o /var/ tmp//ccqHiDhs.s GNU CPP version 3.2.1 [FreeBSD] 20020901 (prerelease) (cpplib) (i386 FreeBSD/ELF) === The next thing you want to do is, invoke /usr/libexec/cc1 (or whatever the program is on your system), manually from the command-line, with all the same command-line flags, and verify that the crash still occurs. The next thing you want to do is to invoke the same program under gdb: gdb /usr/libexec/cc1 == GNU gdb 5.2.0 (FreeBSD) 20020627 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... (no debugging symbols found)... (gdb) run [put all the command-line flags to cc1] == From there, you should be able to see what the backtrace is to where things are crashing. Another helpful thing to do is to follow the instructions at: http://gcc.gnu.org/bugs.html, and use the -save-temps flag to save the preprocessed source code of what is causing gcc to crash. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
