Re: clang 3.2 RC2 miscompiles libgcc?
On 01/11/13 00:39, Dimitry Andric wrote: On 2013-01-08 09:58, Stefan Farfeleder wrote: On Tue, Jan 08, 2013 at 12:21:12AM +0100, Dimitry Andric wrote: ... After a lot of splitting up of unwind-dw2.c, I arrived at _Unwind_Resume which when compiled by clang caused the crashes, but when compiled by gcc ran OK. your patch seems to work just fine. No crashes whatsoever so far. Thank you. I have committed a slighly cleaned-up version of this hack in r245272, so until this is fixed by upstream, everybody will at least have a correctly functioning libgcc on amd64. Since this issue can potentially also occur on stable/9, I will MFC the fix too, after a few days timeout. ___ Very appreciated and thanks. oh signature.asc Description: OpenPGP digital signature
Re: clang 3.2 RC2 miscompiles libgcc?
On 2013-01-11 02:19, O. Hartmann wrote: On 01/11/13 00:39, Dimitry Andric wrote: On 2013-01-08 09:58, Stefan Farfeleder wrote: On Tue, Jan 08, 2013 at 12:21:12AM +0100, Dimitry Andric wrote: ... After a lot of splitting up of unwind-dw2.c, I arrived at _Unwind_Resume which when compiled by clang caused the crashes, but when compiled by gcc ran OK. your patch seems to work just fine. No crashes whatsoever so far. Thank you. I have committed a slighly cleaned-up version of this hack in r245272, so until this is fixed by upstream, everybody will at least have a correctly functioning libgcc on amd64. Since this issue can potentially also occur on stable/9, I will MFC the fix too, after a few days timeout. ___ Very appreciated and thanks. oh For the record, I rebuilt my world/kernel after this commit, and rebuilt VirtualBox, and it now works correctly. Thanks Dimitry! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On 2013-01-08 09:58, Stefan Farfeleder wrote: On Tue, Jan 08, 2013 at 12:21:12AM +0100, Dimitry Andric wrote: ... After a lot of splitting up of unwind-dw2.c, I arrived at _Unwind_Resume which when compiled by clang caused the crashes, but when compiled by gcc ran OK. your patch seems to work just fine. No crashes whatsoever so far. Thank you. I have committed a slighly cleaned-up version of this hack in r245272, so until this is fixed by upstream, everybody will at least have a correctly functioning libgcc on amd64. Since this issue can potentially also occur on stable/9, I will MFC the fix too, after a few days timeout. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On Fri, Jan 11, 2013 at 12:39:44AM +0100, Dimitry Andric wrote: On 2013-01-08 09:58, Stefan Farfeleder wrote: On Tue, Jan 08, 2013 at 12:21:12AM +0100, Dimitry Andric wrote: ... After a lot of splitting up of unwind-dw2.c, I arrived at _Unwind_Resume which when compiled by clang caused the crashes, but when compiled by gcc ran OK. your patch seems to work just fine. No crashes whatsoever so far. Thank you. I have committed a slighly cleaned-up version of this hack in r245272, so until this is fixed by upstream, everybody will at least have a correctly functioning libgcc on amd64. Since this issue can potentially also occur on stable/9, I will MFC the fix too, after a few days timeout. Thanks! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On 7 Jan 2013, at 23:21, Dimitry Andric wrote: This is at least the direction I'm looking at. It seems that in some cases with __builtin_eh_return(), llvm does not see that registers can be clobbered, and it doesn't save and restore them. Do you mean that some registers were clobbered by a prior call? __builtin_eh_return() doesn't return, so whether it clobbers anything or not isn't something that should matter. The preceding call is __builtin_frob_return_addr, which seems to be a no-op, so it shouldn't clobber any registers either... David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On Tue, Jan 08, 2013 at 12:21:12AM +0100, Dimitry Andric wrote: On 2013-01-06 17:03, Stefan Farfeleder wrote: On Sun, Jan 06, 2013 at 03:59:59PM +0100, Dimitry Andric wrote: ... The bug also affects ports software, e.g., I also experienced strange rtorrent segfaults that are now gone. Can you please try the attached patch, which is a very horrid, atrocious hack, and will only work for amd64. Then rebuild libgcc with clang, and please try if this fixes at least some of the crashes... This is at least the direction I'm looking at. It seems that in some cases with __builtin_eh_return(), llvm does not see that registers can be clobbered, and it doesn't save and restore them. After a lot of splitting up of unwind-dw2.c, I arrived at _Unwind_Resume which when compiled by clang caused the crashes, but when compiled by gcc ran OK. Hi Dimitry, your patch seems to work just fine. No crashes whatsoever so far. Thank you. Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On 2013-01-08 09:08, David Chisnall wrote:
On 7 Jan 2013, at 23:21, Dimitry Andric wrote:
This is at least the direction I'm looking at. It seems that in some
cases with __builtin_eh_return(), llvm does not see that registers can
be clobbered, and it doesn't save and restore them.
Do you mean that some registers were clobbered by a prior call?
__builtin_eh_return() doesn't return, so whether it clobbers anything or not
isn't something that should matter. The preceding call is
__builtin_frob_return_addr, which seems to be a no-op, so it shouldn't clobber
any registers either...
No, I mean that gcc seems to take great care in saving and restoring
almost all important registers in a function, if that function contains
a call to __builtin_eh_return.
If you look at expand_eh_return() in contrib/gcc/except.c, you can see
that it sets the special variable 'current_function_calls_eh_return'.
This influences the code generation all over the place, and specifically
the saving of registers in contrib/gcc/config/i386/i386.c:
==
/* Return 1 if we need to save REGNO. */
static int
ix86_save_reg (unsigned int regno, int maybe_eh_return)
{
if (pic_offset_table_rtx
regno == REAL_PIC_OFFSET_TABLE_REGNUM
(regs_ever_live[REAL_PIC_OFFSET_TABLE_REGNUM]
|| current_function_profile
|| current_function_calls_eh_return
|| current_function_uses_const_pool))
{
if (ix86_select_alt_pic_regnum () != INVALID_REGNUM)
return 0;
return 1;
}
if (current_function_calls_eh_return maybe_eh_return)
{
unsigned i;
for (i = 0; ; i++)
{
unsigned test = EH_RETURN_DATA_REGNO (i);
if (test == INVALID_REGNUM)
break;
if (test == regno)
return 1;
}
}
[...]
/* Emit code to save registers in the prologue. */
static void
ix86_emit_save_regs (void)
{
unsigned int regno;
rtx insn;
for (regno = FIRST_PSEUDO_REGISTER; regno-- 0; )
if (ix86_save_reg (regno, true))
{
insn = emit_insn (gen_push (gen_rtx_REG (Pmode, regno)));
RTX_FRAME_RELATED_P (insn) = 1;
}
}
==
On i386, most registers are touched anyway in _Unwind_Resume, so clang
will already save and restore them. But on amd64, there are more
registers than local variables, so clang only seems to save a few; not
enough, in any case. This is why I added the asm statement which
clobbers all those registers, forcing clang to save and restore them.
This fixes most of the crashes I was able to reproduce. I think I still
have another unrelated issue in libgcc with clang, but this only occurs
when compiling the testcases with gcc 4.7, and very high optimization.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
08.01.2013 03:21, Dimitry Andric пишет: Can you please try the attached patch, which is a very horrid, atrocious hack, and will only work for amd64. Then rebuild libgcc with clang, and please try if this fixes at least some of the crashes... The patch fixed building editors/libreoffice. Without this patch the port segfaulted while doing cppunittest. The system: - % uname -a FreeBSD BB051.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r245047: Sat Jan 5 03:19:00 SAMT 2013 b...@bb051.wart.ru:/usr/obj/usr/src/sys/BB64X amd64 % clang --version FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: x86_64-unknown-freebsd10.0 Thread model: posix - Thanks! -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On Sun, Jan 06, 2013 at 04:51:11PM +, David Chisnall wrote: On 6 Jan 2013, at 16:48, Nathan Whitehorn wrote: No. It's completely broken at all optimization levels. There do not appear to be any flags that change the behavior. Building unwind-dw2.c either with gcc or with the previous import of clang in our tree does fix it, however. Do you have an LLVM PR# for this that I can follow? There's http://llvm.org/bugs/show_bug.cgi?id=8541 which I think should be reopened. Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On 2013-01-06 17:03, Stefan Farfeleder wrote: On Sun, Jan 06, 2013 at 03:59:59PM +0100, Dimitry Andric wrote: ... The bug also affects ports software, e.g., I also experienced strange rtorrent segfaults that are now gone. Can you please try the attached patch, which is a very horrid, atrocious hack, and will only work for amd64. Then rebuild libgcc with clang, and please try if this fixes at least some of the crashes... This is at least the direction I'm looking at. It seems that in some cases with __builtin_eh_return(), llvm does not see that registers can be clobbered, and it doesn't save and restore them. After a lot of splitting up of unwind-dw2.c, I arrived at _Unwind_Resume which when compiled by clang caused the crashes, but when compiled by gcc ran OK. Here is a side-by-side overview of the output; sorry for going over any 72-char margin, but this is for illustration. You can see that gcc saves most registers on the stack, and restores them just before the eh return. Clang does not, at least by default: GCC OUTPUT CLANG OUTPUT = = _Unwind_Resume: _Unwind_Resume: # @_Unwind_Resume pushq %rbppushq %rbp movq%rsp, %rbp movq %rsp, %rbp pushq %r15pushq %rdx pushq %r14pushq %rax pushq %r13subq $528, %rsp # imm = 0x210 pushq %r12movq %rdi, -24(%rbp) pushq %rbxmovq %rbp, %rdi pushq %rdxaddq $16, %rdi pushq %raxmovq 8(%rbp), %rdx subq$536, %rsp leaq -264(%rbp), %rcx movq%rdi, -584(%rbp)movq %rdi, -536(%rbp)# 8-byte Spill movq8(%rbp), %rax movq %rcx, %rdi movq%rax, %rdx movq -536(%rbp), %rsi# 8-byte Reload leaq16(%rbp), %rsi callq uw_init_context_1@PLT leaq-336(%rbp), %rdimovabsq $240, %rdx calluw_init_context_1@PLT leaq -264(%rbp), %rcx leaq-576(%rbp), %rdileaq -504(%rbp), %rsi leaq-336(%rbp), %rsimovq %rsi, %rdi movl$240, %edx movq %rcx, %rsi callmemcpy@PLT callq memcpy@PLT movq-584(%rbp), %raxmovq -24(%rbp), %rcx movq16(%rax), %rax cmpq $0, 16(%rcx) testq %rax, %rax jne .LBB0_2 jne .L59leaq -504(%rbp), %rsi leaq-576(%rbp), %rsimovq -24(%rbp), %rdi movq-584(%rbp), %rdicallq _Unwind_RaiseException_Phase2@PLT call_Unwind_RaiseException_Phase2@PLT movl %eax, -508(%rbp) movl%eax, -84(%rbp) jmp .LBB0_3 jmp .L61.LBB0_2: # %if.else .L59: leaq -504(%rbp), %rsi leaq-576(%rbp), %rsimovq -24(%rbp), %rdi movq-584(%rbp), %rdicallq _Unwind_ForcedUnwind_Phase2@PLT call_Unwind_ForcedUnwind_Phase2@PLT movl %eax, -508(%rbp) movl%eax, -84(%rbp) .LBB0_3: # %if.end .L61: cmpl $7, -508(%rbp) cmpl$7, -84(%rbp) je .LBB0_5 je .L62callq abort@PLT
Re: clang 3.2 RC2 miscompiles libgcc?
On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: Here's a minimal test case that reproduces the bug: [...] Until someone fixes this bug, could we apply something like this as a work-around? Stefan Index: gnu/lib/libgcc/Makefile === --- gnu/lib/libgcc/Makefile (revision 245055) +++ gnu/lib/libgcc/Makefile (working copy) @@ -6,6 +6,8 @@ SHLIB_NAME=libgcc_s.so.1 SHLIBDIR?= /lib +CC=gcc + .include bsd.own.mk # # libgcc is linked in last and thus cannot depend on ssp symbols coming ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On 2013-01-06 15:17, Stefan Farfeleder wrote: On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: Here's a minimal test case that reproduces the bug: [...] Until someone fixes this bug, could we apply something like this as a work-around? Stefan Index: gnu/lib/libgcc/Makefile === --- gnu/lib/libgcc/Makefile (revision 245055) +++ gnu/lib/libgcc/Makefile (working copy) @@ -6,6 +6,8 @@ SHLIB_NAME= libgcc_s.so.1 SHLIBDIR?=/lib +CC=gcc + .include bsd.own.mk I think this is a bit overkill approach. We still don't know what the exact cause of the problem is, and this just papers over it. Also, ince the bug is only reproducible by compiling the testcase with g++, could you not compile your crashing programs with clang instead, for now? :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On 01/06/13 09:59, Dimitry Andric wrote: On 2013-01-06 15:17, Stefan Farfeleder wrote: On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: Here's a minimal test case that reproduces the bug: [...] Until someone fixes this bug, could we apply something like this as a work-around? Stefan Index: gnu/lib/libgcc/Makefile === --- gnu/lib/libgcc/Makefile(revision 245055) +++ gnu/lib/libgcc/Makefile(working copy) @@ -6,6 +6,8 @@ SHLIB_NAME=libgcc_s.so.1 SHLIBDIR?=/lib +CC=gcc + .include bsd.own.mk I think this is a bit overkill approach. We still don't know what the exact cause of the problem is, and this just papers over it. Also, ince the bug is only reproducible by compiling the testcase with g++, could you not compile your crashing programs with clang instead, for now? :-) I would very much support this patch. Whatever is going wrong is a critical problem -- although his testcase requires g++, I have lots of code that also crashes when built with clang. The fact that *any* code built with *any* compiler crashes when used with clang-built libgcc is an error. This is quite serious and breaks a *lot* of C++ code. If it can't be fixed now, papering it over is required. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On Sun, Jan 06, 2013 at 03:59:59PM +0100, Dimitry Andric wrote: On 2013-01-06 15:17, Stefan Farfeleder wrote: On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: Here's a minimal test case that reproduces the bug: [...] Until someone fixes this bug, could we apply something like this as a work-around? Stefan Index: gnu/lib/libgcc/Makefile === --- gnu/lib/libgcc/Makefile (revision 245055) +++ gnu/lib/libgcc/Makefile (working copy) @@ -6,6 +6,8 @@ SHLIB_NAME= libgcc_s.so.1 SHLIBDIR?=/lib +CC=gcc + .include bsd.own.mk I think this is a bit overkill approach. We still don't know what the exact cause of the problem is, and this just papers over it. It seems unwise to install a known-to-be-broken libgcc by default, even though the exact cause is not known yet. Also, ince the bug is only reproducible by compiling the testcase with g++, could you not compile your crashing programs with clang instead, for now? :-) The bug also affects ports software, e.g., I also experienced strange rtorrent segfaults that are now gone. Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On 01/06/13 10:29, Nathan Whitehorn wrote: On 01/06/13 09:59, Dimitry Andric wrote: On 2013-01-06 15:17, Stefan Farfeleder wrote: On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: Here's a minimal test case that reproduces the bug: [...] Until someone fixes this bug, could we apply something like this as a work-around? Stefan Index: gnu/lib/libgcc/Makefile === --- gnu/lib/libgcc/Makefile(revision 245055) +++ gnu/lib/libgcc/Makefile(working copy) @@ -6,6 +6,8 @@ SHLIB_NAME=libgcc_s.so.1 SHLIBDIR?=/lib +CC=gcc + .include bsd.own.mk I think this is a bit overkill approach. We still don't know what the exact cause of the problem is, and this just papers over it. Also, ince the bug is only reproducible by compiling the testcase with g++, could you not compile your crashing programs with clang instead, for now? :-) I would very much support this patch. Whatever is going wrong is a critical problem -- although his testcase requires g++, I have lots of code that also crashes when built with clang. The fact that *any* code built with *any* compiler crashes when used with clang-built libgcc is an error. This is quite serious and breaks a *lot* of C++ code. If it can't be fixed now, papering it over is required. -Nathan For whatever it's worth, I verified that this is the same bug I was seeing earlier: only unwind-dw2.c is being miscompiled. The preprocessed versions of this file are identical with both gcc and clang and the problem occurs at all optimization levels with it is built with clang. I tried replacing as many of the __builtin functions as a could with thunks to the gcc versions, with no positive result. The ones I could not replace are __builtin_return_address, __builtin_dwarf_cfa, and __builtin_eh_return. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On 6 Jan 2013, at 14:17, Stefan Farfeleder wrote: On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: Here's a minimal test case that reproduces the bug: [...] Until someone fixes this bug, could we apply something like this as a work-around? Stefan Index: gnu/lib/libgcc/Makefile === --- gnu/lib/libgcc/Makefile (revision 245055) +++ gnu/lib/libgcc/Makefile (working copy) @@ -6,6 +6,8 @@ SHLIB_NAME= libgcc_s.so.1 SHLIBDIR?=/lib +CC= gcc + .include bsd.own.mk # # libgcc is linked in last and thus cannot depend on ssp symbols coming This will break the build entirely for those of us who build without gcc, and as we are planning on removing gcc entirely by the 10.0 timeframe we should be encouraging people to do this, not discouraging it. Does compiling at a lower optimisation level (-O1? -O0) work as a temporary fix? David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On 01/06/13 11:46, David Chisnall wrote: On 6 Jan 2013, at 14:17, Stefan Farfeleder wrote: On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: Here's a minimal test case that reproduces the bug: [...] Until someone fixes this bug, could we apply something like this as a work-around? Stefan Index: gnu/lib/libgcc/Makefile === --- gnu/lib/libgcc/Makefile (revision 245055) +++ gnu/lib/libgcc/Makefile (working copy) @@ -6,6 +6,8 @@ SHLIB_NAME= libgcc_s.so.1 SHLIBDIR?= /lib +CC= gcc + .include bsd.own.mk # # libgcc is linked in last and thus cannot depend on ssp symbols coming This will break the build entirely for those of us who build without gcc, and as we are planning on removing gcc entirely by the 10.0 timeframe we should be encouraging people to do this, not discouraging it. Does compiling at a lower optimisation level (-O1? -O0) work as a temporary fix? No. It's completely broken at all optimization levels. There do not appear to be any flags that change the behavior. Building unwind-dw2.c either with gcc or with the previous import of clang in our tree does fix it, however. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On 6 Jan 2013, at 16:48, Nathan Whitehorn wrote: No. It's completely broken at all optimization levels. There do not appear to be any flags that change the behavior. Building unwind-dw2.c either with gcc or with the previous import of clang in our tree does fix it, however. Do you have an LLVM PR# for this that I can follow? David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On Fri, Jan 04, 2013 at 10:23:34PM +0200, Konstantin Belousov wrote: Thank you for digging more. In fact, it is more likely that there is some bug or incompatibility in c++ unwinder than in the libgcc itself, but as you noted, a compiler bug is also possible. Anyway, I was mostly looking could the backtrace starts in rtld. Rtld bug also cannot be excluded at this stage, but it not much likely. FWIW, the diff between working and non-working assembler can be found at http://people.freebsd.org/~stefanf/tmp/libgcc_s.s.diff . Not that I expect much from that. Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On Wed, Jan 02, 2013 at 02:59:50PM +0100, Stefan Farfeleder wrote:
On Sun, Dec 30, 2012 at 11:17:10PM +0100, Dimitry Andric wrote:
I have been playing with Stefan's testcase for a while now, and while I
can reproduce the crashes, I am still at a loss about the cause. It
does seem to have something to do with throwing exceptions, but I am
still not sure whether I am looking at a bug in boost, gcc, clang, or
libgcc...
Do you happen to have a smaller testcase, by any chance?
Not yet, but I'll try to come up with something smaller.
Here's a minimal test case that reproduces the bug:
$ cat throw-crash.cc
#include stdexcept
void f2(void) {
std::string s;
throw std::runtime_error(foo);
}
void f1(void) {
f2();
}
int main(void) {
try {
std::string s1, s2;
f1();
return 0;
} catch (const std::exception ) {
return 1;
}
}
$ g++ -O2 -finline-limit=0 throw-crash.cc
$ ./a.out
zsh: bus error (core dumped) ./a.out
Stefan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote:
On Wed, Jan 02, 2013 at 02:59:50PM +0100, Stefan Farfeleder wrote:
On Sun, Dec 30, 2012 at 11:17:10PM +0100, Dimitry Andric wrote:
I have been playing with Stefan's testcase for a while now, and while I
can reproduce the crashes, I am still at a loss about the cause. It
does seem to have something to do with throwing exceptions, but I am
still not sure whether I am looking at a bug in boost, gcc, clang, or
libgcc...
Do you happen to have a smaller testcase, by any chance?
Not yet, but I'll try to come up with something smaller.
Here's a minimal test case that reproduces the bug:
$ cat throw-crash.cc
#include stdexcept
void f2(void) {
std::string s;
throw std::runtime_error(foo);
}
void f1(void) {
f2();
}
int main(void) {
try {
std::string s1, s2;
f1();
return 0;
} catch (const std::exception ) {
return 1;
}
}
$ g++ -O2 -finline-limit=0 throw-crash.cc
$ ./a.out
zsh: bus error (core dumped) ./a.out
What is the backtrace ?
Compile the system libraries (ld-elf, libc, libgcc etc) with the
debugging information and obtain the backtrace once more.
pgpqQWwruELDD.pgp
Description: PGP signature
Re: clang 3.2 RC2 miscompiles libgcc?
On Fri, Jan 04, 2013 at 08:14:38PM +0200, Konstantin Belousov wrote:
On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote:
Here's a minimal test case that reproduces the bug:
$ cat throw-crash.cc
#include stdexcept
void f2(void) {
std::string s;
throw std::runtime_error(foo);
}
void f1(void) {
f2();
}
int main(void) {
try {
std::string s1, s2;
f1();
return 0;
} catch (const std::exception ) {
return 1;
}
}
$ g++ -O2 -finline-limit=0 throw-crash.cc
$ ./a.out
zsh: bus error (core dumped) ./a.out
What is the backtrace ?
Compile the system libraries (ld-elf, libc, libgcc etc) with the
debugging information and obtain the backtrace once more.
I'm afraid the backtrace is not really interesting:
Program received signal SIGBUS, Bus error.
std::string::_Rep::_M_dispose (this=0x7fffd62fe8, __a=@0x7fffd628)
at atomicity.h:69
69 _Atomic_word __result = *__mem;
(gdb) bt
#0 std::string::_Rep::_M_dispose (this=0x7fffd62fe8, __a=@0x7fffd628)
at atomicity.h:69
#1 0x00080089d168 in ~basic_string (this=0x7fffd62fe8)
at basic_string.h:482
#2 0x00401038 in main () at throw-crash.cc:16
I think the stack is somehow corrupted after the exception was
performed. As with the original test case, loading an old libgcc_s.so.1
instead makes the program run correctly.
It seems the std::string destructor is called with an invalid this
pointer for s2:
(gdb) r
Starting program: /usr/home/stefan/scratch/a.out
Breakpoint 1, main () at throw-crash.cc:12
12 int main(void) {
(gdb) b _Unwind_RaiseException
Breakpoint 2 at 0x800d420b4
(gdb) c
Continuing.
Breakpoint 2, 0x000800d420b4 in _Unwind_RaiseException ()
from /lib/libgcc_s.so.1
(gdb) f 2
#2 0x00400f51 in f2 () at throw-crash.cc:5
5 throw std::runtime_error(foo);
(gdb) p s
$1 = (string *) 0x7fffd600
(gdb) up
#3 0x00400fe2 in main () at throw-crash.cc:15
15 f1();
(gdb) p s1
$2 = (string *) 0x7fffd650
(gdb) p s2
$3 = (string *) 0x7fffd640
(gdb) b 'std::basic_stringchar, std::char_traitschar, std::allocatorchar
::~basic_string()'
Breakpoint 3 at 0x80089d154: file basic_string.h, line 482.
(gdb) c
Continuing.
Breakpoint 3, ~basic_string (this=0x7fffd600) at basic_string.h:279
279 _M_data() const
(gdb) c
Continuing.
Breakpoint 3, ~basic_string (this=0x7fffd640) at basic_string.h:279
279 _M_data() const
(gdb) c
Continuing.
Breakpoint 3, ~basic_string (this=0x7fffd60f) at basic_string.h:279
279 _M_data() const
So, the address of s2 is 0x7fffd640, but the dtor is called with
0x7fffd60f which is also very unaligned. I think this is the reason
for the crash.
Stefan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On Fri, Jan 04, 2013 at 08:06:02PM +0100, Stefan Farfeleder wrote:
On Fri, Jan 04, 2013 at 08:14:38PM +0200, Konstantin Belousov wrote:
On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote:
Here's a minimal test case that reproduces the bug:
$ cat throw-crash.cc
#include stdexcept
void f2(void) {
std::string s;
throw std::runtime_error(foo);
}
void f1(void) {
f2();
}
int main(void) {
try {
std::string s1, s2;
f1();
return 0;
} catch (const std::exception ) {
return 1;
}
}
$ g++ -O2 -finline-limit=0 throw-crash.cc
$ ./a.out
zsh: bus error (core dumped) ./a.out
What is the backtrace ?
Compile the system libraries (ld-elf, libc, libgcc etc) with the
debugging information and obtain the backtrace once more.
I'm afraid the backtrace is not really interesting:
Program received signal SIGBUS, Bus error.
std::string::_Rep::_M_dispose (this=0x7fffd62fe8, __a=@0x7fffd628)
at atomicity.h:69
69 _Atomic_word __result = *__mem;
(gdb) bt
#0 std::string::_Rep::_M_dispose (this=0x7fffd62fe8, __a=@0x7fffd628)
at atomicity.h:69
#1 0x00080089d168 in ~basic_string (this=0x7fffd62fe8)
at basic_string.h:482
#2 0x00401038 in main () at throw-crash.cc:16
I think the stack is somehow corrupted after the exception was
performed. As with the original test case, loading an old libgcc_s.so.1
instead makes the program run correctly.
It seems the std::string destructor is called with an invalid this
pointer for s2:
(gdb) r
Starting program: /usr/home/stefan/scratch/a.out
Breakpoint 1, main () at throw-crash.cc:12
12 int main(void) {
(gdb) b _Unwind_RaiseException
Breakpoint 2 at 0x800d420b4
(gdb) c
Continuing.
Breakpoint 2, 0x000800d420b4 in _Unwind_RaiseException ()
from /lib/libgcc_s.so.1
(gdb) f 2
#2 0x00400f51 in f2 () at throw-crash.cc:5
5 throw std::runtime_error(foo);
(gdb) p s
$1 = (string *) 0x7fffd600
(gdb) up
#3 0x00400fe2 in main () at throw-crash.cc:15
15 f1();
(gdb) p s1
$2 = (string *) 0x7fffd650
(gdb) p s2
$3 = (string *) 0x7fffd640
(gdb) b 'std::basic_stringchar, std::char_traitschar, std::allocatorchar
::~basic_string()'
Breakpoint 3 at 0x80089d154: file basic_string.h, line 482.
(gdb) c
Continuing.
Breakpoint 3, ~basic_string (this=0x7fffd600) at basic_string.h:279
279 _M_data() const
(gdb) c
Continuing.
Breakpoint 3, ~basic_string (this=0x7fffd640) at basic_string.h:279
279 _M_data() const
(gdb) c
Continuing.
Breakpoint 3, ~basic_string (this=0x7fffd60f) at basic_string.h:279
279 _M_data() const
So, the address of s2 is 0x7fffd640, but the dtor is called with
0x7fffd60f which is also very unaligned. I think this is the reason
for the crash.
Thank you for digging more.
In fact, it is more likely that there is some bug or incompatibility in
c++ unwinder than in the libgcc itself, but as you noted, a compiler bug
is also possible.
Anyway, I was mostly looking could the backtrace starts in rtld. Rtld bug
also cannot be excluded at this stage, but it not much likely.
pgpM6TAs72wPh.pgp
Description: PGP signature
Re: clang 3.2 RC2 miscompiles libgcc?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/04/2013 12:23, Konstantin Belousov wrote:
On Fri, Jan 04, 2013 at 08:06:02PM +0100, Stefan Farfeleder wrote:
On Fri, Jan 04, 2013 at 08:14:38PM +0200, Konstantin Belousov
wrote:
On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder
wrote:
Here's a minimal test case that reproduces the bug:
$ cat throw-crash.cc #include stdexcept
void f2(void) { std::string s; throw
std::runtime_error(foo); }
void f1(void) { f2(); }
int main(void) { try { std::string s1, s2; f1(); return 0; }
catch (const std::exception ) { return 1; } } $ g++ -O2
-finline-limit=0 throw-crash.cc $ ./a.out zsh: bus error
(core dumped) ./a.out
What is the backtrace ? Compile the system libraries (ld-elf,
libc, libgcc etc) with the debugging information and obtain the
backtrace once more.
I'm afraid the backtrace is not really interesting:
Program received signal SIGBUS, Bus error.
std::string::_Rep::_M_dispose (this=0x7fffd62fe8,
__a=@0x7fffd628) at atomicity.h:69 69 _Atomic_word
__result = *__mem; (gdb) bt #0 std::string::_Rep::_M_dispose
(this=0x7fffd62fe8, __a=@0x7fffd628) at atomicity.h:69 #1
0x00080089d168 in ~basic_string (this=0x7fffd62fe8) at
basic_string.h:482 #2 0x00401038 in main () at
throw-crash.cc:16
I think the stack is somehow corrupted after the exception was
performed. As with the original test case, loading an old
libgcc_s.so.1 instead makes the program run correctly.
It seems the std::string destructor is called with an invalid
this pointer for s2:
(gdb) r Starting program: /usr/home/stefan/scratch/a.out
Breakpoint 1, main () at throw-crash.cc:12 12 int main(void)
{ (gdb) b _Unwind_RaiseException Breakpoint 2 at 0x800d420b4
(gdb) c Continuing.
Breakpoint 2, 0x000800d420b4 in _Unwind_RaiseException ()
from /lib/libgcc_s.so.1 (gdb) f 2 #2 0x00400f51 in f2 ()
at throw-crash.cc:5 5 throw std::runtime_error(foo);
(gdb) p s $1 = (string *) 0x7fffd600 (gdb) up #3
0x00400fe2 in main () at throw-crash.cc:15 15
f1(); (gdb) p s1 $2 = (string *) 0x7fffd650 (gdb) p s2 $3 =
(string *) 0x7fffd640 (gdb) b 'std::basic_stringchar,
std::char_traitschar, std::allocatorchar ::~basic_string()'
Breakpoint 3 at 0x80089d154: file basic_string.h, line 482.
(gdb) c Continuing.
Breakpoint 3, ~basic_string (this=0x7fffd600) at
basic_string.h:279 279 _M_data() const (gdb) c
Continuing.
Breakpoint 3, ~basic_string (this=0x7fffd640) at
basic_string.h:279 279 _M_data() const (gdb) c
Continuing.
Breakpoint 3, ~basic_string (this=0x7fffd60f) at
basic_string.h:279 279 _M_data() const
So, the address of s2 is 0x7fffd640, but the dtor is called
with 0x7fffd60f which is also very unaligned. I think this is
the reason for the crash.
Thank you for digging more.
In fact, it is more likely that there is some bug or
incompatibility in c++ unwinder than in the libgcc itself, but as
you noted, a compiler bug is also possible.
Anyway, I was mostly looking could the backtrace starts in rtld.
Rtld bug also cannot be excluded at this stage, but it not much
likely.
Since this is similar to the pain I was seeing rebuilding everything
with clang so I have been following this thread with much interest.
Just to add more data, I get different results. This is all i386.
gcc v464 built using an earlier clang from -current world/kernel
r243027. boost was also built using this revision.
$ /usr/local/bin/g++46 -O2 -I/usr/local/include -L/usr/local/lib
- -lboost_program_options -o unwinder unwinder.cc
[atkinson@moby ~/dev]$ ldd unwinder
unwinder:
libboost_program_options.so =
/usr/local/lib/libboost_program_options.so (0x2806e000)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x280c2000)
libm.so.5 = /lib/libm.so.5 (0x281a1000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x281c2000)
libc.so.7 = /lib/libc.so.7 (0x281cd000)
libthr.so.3 = /lib/libthr.so.3 (0x28317000)
[atkinson@moby ~/dev]$ ./unwinder
Abort trap (core dumped)
clang 32 built from -current world/kernel r244958 works just fine.
$ c++ -O2 -I/usr/local/include -L/usr/local/lib
- -lboost_program_options -o unwinder unwinder.cc
[atkinson@moby ~/dev]$ ./unwinder
[atkinson@moby ~/dev]$ ldd unwinder
unwinder:
libboost_program_options.so =
/usr/local/lib/libboost_program_options.so (0x2806d000)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x280c1000)
libm.so.5 = /lib/libm.so.5 (0x281a)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x281c1000)
libc.so.7 = /lib/libc.so.7 (0x281cc000)
libthr.so.3 = /lib/libthr.so.3 (0x28316000)
It might be useful to expand -O2 into all it's -f components and
elminate them one by one until the crash is not reproducable.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
Comment: Using
Re: clang 3.2 RC2 miscompiles libgcc?
On 01/04/13 15:23, Konstantin Belousov wrote:
On Fri, Jan 04, 2013 at 08:06:02PM +0100, Stefan Farfeleder wrote:
On Fri, Jan 04, 2013 at 08:14:38PM +0200, Konstantin Belousov wrote:
On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote:
Here's a minimal test case that reproduces the bug:
$ cat throw-crash.cc
#include stdexcept
void f2(void) {
std::string s;
throw std::runtime_error(foo);
}
void f1(void) {
f2();
}
int main(void) {
try {
std::string s1, s2;
f1();
return 0;
} catch (const std::exception ) {
return 1;
}
}
$ g++ -O2 -finline-limit=0 throw-crash.cc
$ ./a.out
zsh: bus error (core dumped) ./a.out
What is the backtrace ?
Compile the system libraries (ld-elf, libc, libgcc etc) with the
debugging information and obtain the backtrace once more.
I'm afraid the backtrace is not really interesting:
Program received signal SIGBUS, Bus error.
std::string::_Rep::_M_dispose (this=0x7fffd62fe8, __a=@0x7fffd628)
at atomicity.h:69
69 _Atomic_word __result = *__mem;
(gdb) bt
#0 std::string::_Rep::_M_dispose (this=0x7fffd62fe8,
__a=@0x7fffd628)
at atomicity.h:69
#1 0x00080089d168 in ~basic_string (this=0x7fffd62fe8)
at basic_string.h:482
#2 0x00401038 in main () at throw-crash.cc:16
I think the stack is somehow corrupted after the exception was
performed. As with the original test case, loading an old libgcc_s.so.1
instead makes the program run correctly.
It seems the std::string destructor is called with an invalid this
pointer for s2:
(gdb) r
Starting program: /usr/home/stefan/scratch/a.out
Breakpoint 1, main () at throw-crash.cc:12
12 int main(void) {
(gdb) b _Unwind_RaiseException
Breakpoint 2 at 0x800d420b4
(gdb) c
Continuing.
Breakpoint 2, 0x000800d420b4 in _Unwind_RaiseException ()
from /lib/libgcc_s.so.1
(gdb) f 2
#2 0x00400f51 in f2 () at throw-crash.cc:5
5 throw std::runtime_error(foo);
(gdb) p s
$1 = (string *) 0x7fffd600
(gdb) up
#3 0x00400fe2 in main () at throw-crash.cc:15
15 f1();
(gdb) p s1
$2 = (string *) 0x7fffd650
(gdb) p s2
$3 = (string *) 0x7fffd640
(gdb) b 'std::basic_stringchar, std::char_traitschar,
std::allocatorchar ::~basic_string()'
Breakpoint 3 at 0x80089d154: file basic_string.h, line 482.
(gdb) c
Continuing.
Breakpoint 3, ~basic_string (this=0x7fffd600) at basic_string.h:279
279 _M_data() const
(gdb) c
Continuing.
Breakpoint 3, ~basic_string (this=0x7fffd640) at basic_string.h:279
279 _M_data() const
(gdb) c
Continuing.
Breakpoint 3, ~basic_string (this=0x7fffd60f) at basic_string.h:279
279 _M_data() const
So, the address of s2 is 0x7fffd640, but the dtor is called with
0x7fffd60f which is also very unaligned. I think this is the reason
for the crash.
Thank you for digging more.
In fact, it is more likely that there is some bug or incompatibility in
c++ unwinder than in the libgcc itself, but as you noted, a compiler bug
is also possible.
Anyway, I was mostly looking could the backtrace starts in rtld. Rtld bug
also cannot be excluded at this stage, but it not much likely.
If this is the same bug I was seeing, recompiling only the file
unwind-dw2.c in libgcc with GCC/old clang, leaving everything else the
same, fixed everything. This would lead me to suspect an error in one of
the many __builtins called by unwind-dw2.c.
-Nathan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On Sun, Dec 30, 2012 at 11:17:10PM +0100, Dimitry Andric wrote: I have been playing with Stefan's testcase for a while now, and while I can reproduce the crashes, I am still at a loss about the cause. It does seem to have something to do with throwing exceptions, but I am still not sure whether I am looking at a bug in boost, gcc, clang, or libgcc... Do you happen to have a smaller testcase, by any chance? Not yet, but I'll try to come up with something smaller. Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On 2 January 2013 08:59, Stefan Farfeleder stef...@freebsd.org wrote: On Sun, Dec 30, 2012 at 11:17:10PM +0100, Dimitry Andric wrote: I have been playing with Stefan's testcase for a while now, and while I can reproduce the crashes, I am still at a loss about the cause. It does seem to have something to do with throwing exceptions, but I am still not sure whether I am looking at a bug in boost, gcc, clang, or libgcc... Do you happen to have a smaller testcase, by any chance? Not yet, but I'll try to come up with something smaller. Take a look at devel/delta as well as creduce (require ToT clang so it is unported at this time) to help you with finding minimal testcase. If you need help, let me know. -- Eitan Adler ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On 2012-12-27 16:15, Nathan Whitehorn wrote: On 12/27/12 09:07, Stefan Farfeleder wrote: I noticed that most of my C++ applications in recent versions of FreeBSD head suddenly crash without me recompiling them. I tracked it down to r243830 which imported a new clang version. The new clang seems to compile libgcc in a wrong or at least incompatible way with what gcc expects. In fact, the breakage only occurs with libgcc compiled by a post-r243830 clang and an application compiled with g++ -O2. For me, the crash happens with boost::program_options, but I'm not sure if that is necessary for the crash. I've seen what I think is the same thing due to a miscompilation of unwind-dw2.c that caused crashes related to cross-shared-object exception handling. It seems to have been fixed with the 3.2 release but I haven't tested it too thoroughly yet. I have been playing with Stefan's testcase for a while now, and while I can reproduce the crashes, I am still at a loss about the cause. It does seem to have something to do with throwing exceptions, but I am still not sure whether I am looking at a bug in boost, gcc, clang, or libgcc... Do you happen to have a smaller testcase, by any chance? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
clang 3.2 RC2 miscompiles libgcc?
Hi,
I noticed that most of my C++ applications in recent versions of FreeBSD
head suddenly crash without me recompiling them. I tracked it down to
r243830 which imported a new clang version. The new clang seems to
compile libgcc in a wrong or at least incompatible way with what gcc
expects. In fact, the breakage only occurs with libgcc compiled by a
post-r243830 clang and an application compiled with g++ -O2. For me, the
crash happens with boost::program_options, but I'm not sure if that is
necessary for the crash.
$ cat po.cc
#include boost/program_options.hpp
int main(void) {
namespace po = boost::program_options;
const char *argv[] = { a.out, -x, 0 };
po::options_description options(Options);
options.add_options()(bla, );
try {
po::variables_map vm;
po::store(po::parse_command_line(2, argv, options), vm);
notify(vm);
return 0;
} catch (const std::exception ex) {
return 1;
}
}
$ g++ -O2 -I /usr/local/include -L /usr/local/lib -lboost_program_options po.cc
$ ./a.out
zsh: segmentation fault (core dumped) ./a.out
$ ldd ./a.out
./a.out:
libboost_program_options.so =
/usr/local/lib/libboost_program_options.so (0x800821000)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x800a7e000)
libm.so.5 = /lib/libm.so.5 (0x800d7c000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x800f9e000)
libc.so.7 = /lib/libc.so.7 (0x8011ab000)
libthr.so.3 = /lib/libthr.so.3 (0x801523000)
$ ls /usr/home/stefan/scratch/r243829
libgcc_s.so.1
$ LD_LIBRARY_PATH=/usr/home/stefan/scratch/r243829 ./a.out
$ valgrind ./a.out
==47491== Memcheck, a memory error detector
==47491== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==47491== Using Valgrind-3.8.0 and LibVEX; rerun with -h for copyright info
==47491== Command: ./a.out
==47491==
==47491== Invalid read of size 8
==47491==at 0x405DAA: boost::program_options::basic_parsed_optionschar
boost::program_options::parse_command_linechar(int, char const* const*,
boost::program_options::options_description const, int,
boost::function1std::pairstd::string, std::string, std::string const) (in
/usr/home/stefan/scratch/a.out)
==47491==by 0x401E7D: main (in /usr/home/stefan/scratch/a.out)
==47491== Address 0x2800ef8 is 24 bytes inside a block of size 27 alloc'd
==47491==at 0x1009FB6: malloc (in
/usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==47491==by 0x213F95A: operator new(unsigned long) (in
/usr/lib/libsupc++.so.1)
==47491==by 0x14F08D2: ??? (in /usr/lib/libstdc++.so.6)
==47491==by 0x14EDCFD: std::basic_stringchar, std::char_traitschar,
std::allocatorchar ::basic_string(std::string const, unsigned long,
unsigned long) (in /usr/lib/libstdc++.so.6)
==47491==by 0x1234B12:
boost::program_options::detail::cmdline::parse_short_option(std::vectorstd::string,
std::allocatorstd::string ) (in
/usr/local/lib/libboost_program_options.so.4)
==47491==by 0x123843A:
boost::detail::function::function_obj_invoker1boost::_bi::bind_tstd::vectorboost::program_options::basic_optionchar,
std::allocatorboost::program_options::basic_optionchar ,
boost::_mfi::mf1std::vectorboost::program_options::basic_optionchar,
std::allocatorboost::program_options::basic_optionchar ,
boost::program_options::detail::cmdline, std::vectorstd::string,
std::allocatorstd::string ,
boost::_bi::list2boost::_bi::valueboost::program_options::detail::cmdline*,
boost::arg1 , std::vectorboost::program_options::basic_optionchar,
std::allocatorboost::program_options::basic_optionchar ,
std::vectorstd::string, std::allocatorstd::string
::invoke(boost::detail::function::function_buffer, std::vectorstd::string,
std::allocatorstd::string ) (in
/usr/local/lib/libboost_program_options.so.4)
==47491==by 0x12367C1: boost::program_options::detail::cmdline::run() (in
/usr/local/lib/libboost_program_options.so.4)
==47491==by 0x4051D5:
boost::program_options::basic_command_line_parserchar::run() (in
/usr/home/stefan/scratch/a.out)
==47491==by 0x405B7A: boost::program_options::basic_parsed_optionschar
boost::program_options::parse_command_linechar(int, char const* const*,
boost::program_options::options_description const, int,
boost::function1std::pairstd::string, std::string, std::string const) (in
/usr/home/stefan/scratch/a.out)
==47491==by 0x401E7D: main (in /usr/home/stefan/scratch/a.out)
==47491==
==47491== Jump to the invalid address stated on the next line
==47491==at 0x782D: ???
==47491==by 0x405DBF: boost::program_options::basic_parsed_optionschar
boost::program_options::parse_command_linechar(int, char const* const*,
boost::program_options::options_description const, int,
boost::function1std::pairstd::string, std::string, std::string const) (in
/usr/home/stefan/scratch/a.out)
==47491==by 0x401E7D: main (in /usr/home/stefan/scratch/a.out)
==47491== Address 0x782d is not stack'd, malloc'd or (recently) free'd
==47491
Re: clang 3.2 RC2 miscompiles libgcc?
On 12/27/12 09:07, Stefan Farfeleder wrote: Hi, I noticed that most of my C++ applications in recent versions of FreeBSD head suddenly crash without me recompiling them. I tracked it down to r243830 which imported a new clang version. The new clang seems to compile libgcc in a wrong or at least incompatible way with what gcc expects. In fact, the breakage only occurs with libgcc compiled by a post-r243830 clang and an application compiled with g++ -O2. For me, the crash happens with boost::program_options, but I'm not sure if that is necessary for the crash. I've seen what I think is the same thing due to a miscompilation of unwind-dw2.c that caused crashes related to cross-shared-object exception handling. It seems to have been fixed with the 3.2 release but I haven't tested it too thoroughly yet. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On Thu, Dec 27, 2012 at 09:15:01AM -0600, Nathan Whitehorn wrote: On 12/27/12 09:07, Stefan Farfeleder wrote: Hi, I noticed that most of my C++ applications in recent versions of FreeBSD head suddenly crash without me recompiling them. I tracked it down to r243830 which imported a new clang version. The new clang seems to compile libgcc in a wrong or at least incompatible way with what gcc expects. In fact, the breakage only occurs with libgcc compiled by a post-r243830 clang and an application compiled with g++ -O2. For me, the crash happens with boost::program_options, but I'm not sure if that is necessary for the crash. I've seen what I think is the same thing due to a miscompilation of unwind-dw2.c that caused crashes related to cross-shared-object exception handling. It seems to have been fixed with the 3.2 release but I haven't tested it too thoroughly yet. Thanks for the confirmation. The cross-dso requirement would explain why my simpler approaches to reproduce it didn't work. But for me there's no difference between RC2 and release (FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221), both cause my applications to crash. Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Tested wanted: BSD-licensed libgcc replacement, libcompiler_rt
On 22-10-2010 16:30, Ed Schouten wrote: Hello everyone, At EuroBSDCon I was talking with some committers active in the area of Clang (brooks, kwm, others) about replacing our libgcc shipped with GCC 4.2.1 with a BSD-licensed version. The LLVM folks have a BSD licensed implementation called libcompiler_rt. See: http://compiler-rt.llvm.org/ [...] I've created a branch in Subversion which replaces libgcc.a and libgcc_p.a with libcompiler_rt.a and libcompiler_rt_p.a and symlinks it to the original names. It seems to survive a `make universe' and it works properly on at least amd64. [...] How to test this: - Check out the branch from SVN: svn co svn://svn.freebsd.org/base/user/ed/compiler-rt/ - Rebuild and reinstall world (and kernel). - Rebuild all your software (yes, I know it's unfortunate). - See whether software crashes or misbehaves, while it didn't do that previously. I noticed that the nvidia driver (from ports/x11/nvidia-driver*) needs to be recompiled after upgrading from HEAD to this branch. If you don't, it will load, but cause a panic when used by X. Rene ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Tested wanted: BSD-licensed libgcc replacement, libcompiler_rt
Hi all, * Ed Schouten e...@80386.nl, 20101022 16:30: At EuroBSDCon I was talking with some committers active in the area of Clang (brooks, kwm, others) about replacing our libgcc shipped with GCC 4.2.1 with a BSD-licensed version. The LLVM folks have a BSD licensed implementation called libcompiler_rt. See: http://compiler-rt.llvm.org/ I was talking with Robert Watson about this the other day. The codebase of compiler-rt also contains the libBlocksRuntime.so library, which is fundamental in making Grand Central Dispatch (GCD) work. Because of its small size (12 KB), I think I'll also include it in the import. This means that after the import, libdispatch is the only port needed to make Grand Central Dispatch work on FreeBSD HEAD. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpyBb6J3YDS1.pgp Description: PGP signature
Tested wanted: BSD-licensed libgcc replacement, libcompiler_rt
Hello everyone, At EuroBSDCon I was talking with some committers active in the area of Clang (brooks, kwm, others) about replacing our libgcc shipped with GCC 4.2.1 with a BSD-licensed version. The LLVM folks have a BSD licensed implementation called libcompiler_rt. See: http://compiler-rt.llvm.org/ Right now it is already complete enough to replace libgcc.a and libgcc_p.a (mostly math rountines), but it doesn't yet implement the functionality (e.g. unwinder) to replace libgcc_eh.a, libgcc_eh_p.a and libgcc_s.so.1. I've created a branch in Subversion which replaces libgcc.a and libgcc_p.a with libcompiler_rt.a and libcompiler_rt_p.a and symlinks it to the original names. It seems to survive a `make universe' and it works properly on at least amd64. Right now the only issue I can think of, is that __clear_cache() is broken on ARM, but that can be fixed trivially. My plan would be to commit this work to HEAD by the end of November (1 month from now), but it would be nice if it could get some more testing in the mean time, especially on non-x86 architectures. How to test this: - Check out the branch from SVN: svn co svn://svn.freebsd.org/base/user/ed/compiler-rt/ - Rebuild and reinstall world (and kernel). - Rebuild all your software (yes, I know it's unfortunate). - See whether software crashes or misbehaves, while it didn't do that previously. In the mean time, I'll see if I can get the Ports folks to run an exp-run with this branch, which should already give some coverage. Thanks! -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgp4nEKTk6e5K.pgp Description: PGP signature
Re: Tested wanted: BSD-licensed libgcc replacement, libcompiler_rt
* Ed Schouten e...@80386.nl, 20101022 16:30: - Rebuild all your software (yes, I know it's unfortunate). Right after I sent this, I thought I'd better clarify this. You don't need to rebuild your software. This change will not break the existing ABI. This step is just mentioned here, since libgcc.a is statically linked into applications. Simply rebuilding and reinstall world is not sufficient to make 3rd party applications use this. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgph9jTT1tKjk.pgp Description: PGP signature
symbol versioning on libgcc?
I know that several libraries in FreeBSD uses symbol versioning. In looking through src/ I was unable to determine whether symbol versioning is used on libgcc. Any guidance would be appreciated. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: symbol versioning on libgcc?
on 30/08/2010 20:32 Steve Kargl said the following: I know that several libraries in FreeBSD uses symbol versioning. In looking through src/ I was unable to determine whether symbol versioning is used on libgcc. Any guidance would be appreciated. Check out output of e.g. objdump -T /usr/lib/libgcc_s.so -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: symbol versioning on libgcc?
On Mon, Aug 30, 2010 at 08:43:40PM +0300, Andriy Gapon wrote: on 30/08/2010 20:32 Steve Kargl said the following: I know that several libraries in FreeBSD uses symbol versioning. In looking through src/ I was unable to determine whether symbol versioning is used on libgcc. Any guidance would be appreciated. Check out output of e.g. objdump -T /usr/lib/libgcc_s.so Thanks. I had forgotten about objdump. A search for Symbol.map in src/ mislead me into believing the version was not happening. Further searching found the Makefile chuck that builds the map in src/gnu/lib/libgcc/Makefile. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: symbol versioning on libgcc?
Steve Kargl wrote: I know that several libraries in FreeBSD uses symbol versioning. In looking through src/ I was unable to determine whether symbol versioning is used on libgcc. Any guidance would be appreciated. I don't think it is. I haven't poked at any sources, but there are no FBSD* symbols in /usr/lib/libgcc_s.so, which is what's used in symbol versioning in, say, /lib/libc.so.7. -Boris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: symbol versioning on libgcc?
Alexander Kabaev wrote: On Mon, 30 Aug 2010 13:36:03 -0400 Boris Kochergin sp...@acm.poly.edu wrote: Steve Kargl wrote: I know that several libraries in FreeBSD uses symbol versioning. In looking through src/ I was unable to determine whether symbol versioning is used on libgcc. Any guidance would be appreciated. I don't think it is. I haven't poked at any sources, but there are no FBSD* symbols in /usr/lib/libgcc_s.so, which is what's used in symbol versioning in, say, /lib/libc.so.7. -Boris And above is wrong. Just for the record. What FBSD* symbol versions have to do with the library independently versioned by FSF? My interpretation of the question was whether libgcc used FreeBSD symbol versioning. If that wasn't it, then indeed, one has nothing to do with the other. -Boris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: symbol versioning on libgcc?
On Mon, Aug 30, 2010 at 02:51:16PM -0400, Alexander Kabaev wrote: On Mon, 30 Aug 2010 13:36:03 -0400 Boris Kochergin sp...@acm.poly.edu wrote: Steve Kargl wrote: I know that several libraries in FreeBSD uses symbol versioning. In looking through src/ I was unable to determine whether symbol versioning is used on libgcc. Any guidance would be appreciated. I don't think it is. I haven't poked at any sources, but there are no FBSD* symbols in /usr/lib/libgcc_s.so, which is what's used in symbol versioning in, say, /lib/libc.so.7. -Boris And above is wrong. Just for the record. What FBSD* symbol versions have to do with the library independently versioned by FSF? I'm trying to test a gfortran 4.6.0 patch that implements REAL(16), which means that TFmode needs to be supported. The GCC infrastructure currently does not build with TFmode on FreeBSD, and so a patch has been created. The last item that needs attention is symbol versioning. See the thread starting at http://gcc.gnu.org/ml/fortran/2010-08/msg00431.html -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: symbol versioning on libgcc?
On Mon, 30 Aug 2010 13:36:03 -0400 Boris Kochergin sp...@acm.poly.edu wrote: Steve Kargl wrote: I know that several libraries in FreeBSD uses symbol versioning. In looking through src/ I was unable to determine whether symbol versioning is used on libgcc. Any guidance would be appreciated. I don't think it is. I haven't poked at any sources, but there are no FBSD* symbols in /usr/lib/libgcc_s.so, which is what's used in symbol versioning in, say, /lib/libc.so.7. -Boris And above is wrong. Just for the record. What FBSD* symbol versions have to do with the library independently versioned by FSF? -- Alexander Kabaev signature.asc Description: PGP signature
Re: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
On Sat, May 11, 2002 at 10:33:03AM -0700, David O'Brien wrote: On Sat, May 11, 2002 at 12:35:38PM +0300, Ruslan Ermilov wrote: I say again, the malloc usage is not in c-parse.in, it is in the parser driver produced by Byacc. OK, now that you've explained it: I'll look this patch over carefully, but at first glance it all seems like stylistic changes. Does it fix a bug, or you just don't like how I did things? The changes are mostly _not_ stylistic like .ORDER with one argument not making any sense. The reason of this patch is as before -- to avoid redefining system Yacc building rules. The changes also fix the -j buildworld breakage in gnu/usr.bin/cc/cc1plus: # cd gnu/usr.bin/cc/cc1plus # make -j8 depend make: don't know how to make y.tab.h. Stop There're also some unrelated changes sitting in my tree like removing old cruft, which I will submit later when the dust settles down. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg38230/pgp0.pgp Description: PGP signature
Re: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
On Sat, May 11, 2002 at 10:33:03AM -0700, David O'Brien wrote: I'll look this patch over carefully, but at first glance it all seems like stylistic changes. Does it fix a bug, or you just don't like how I did things? The changes are mostly _not_ stylistic like .ORDER with one argument not making any sense. The reason of this patch is as before -- to avoid redefining system Yacc building rules. The changes also fix the -j buildworld breakage in gnu/usr.bin/cc/cc1plus: Maybe they are cleaner to you -- but the YACC rules for GCC are rather complicated and what I use is much more direct. You way requires me to remember the 3-4 different ways the YACC _implicit_ rules can affect the build. I feel that for every except you (and maybe BDE) the explicit rules are clearer and more straight forward. I do not see anything wrong with redefining system implicit YACC rules. You have repeatedly hounded me for quite a while about GCC. Since so much of my blood and sweat are not acceptable to you, I encourage you to become the GCC maintainer and do everything to your heart's desire. People are really making me regret that I sweated over GCC 3 to bring it into our tree for all of our architectures and to get many serious bugs fixed in the FSF CVS repository. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
On Sun, May 12, 2002 at 04:43:33AM -0700, David O'Brien wrote: On Sat, May 11, 2002 at 10:33:03AM -0700, David O'Brien wrote: I'll look this patch over carefully, but at first glance it all seems like stylistic changes. Does it fix a bug, or you just don't like how I did things? The changes are mostly _not_ stylistic like .ORDER with one argument not making any sense. The reason of this patch is as before -- to avoid redefining system Yacc building rules. The changes also fix the -j buildworld breakage in gnu/usr.bin/cc/cc1plus: Maybe they are cleaner to you -- but the YACC rules for GCC are rather complicated and what I use is much more direct. You way requires me to remember the 3-4 different ways the YACC _implicit_ rules can affect the build. I feel that for every except you (and maybe BDE) the explicit rules are clearer and more straight forward. I do not see anything wrong with redefining system implicit YACC rules. They are not wrong, they are just redundant for most of the part. My changes tell how to build FreeBSD versions of YACC input (.y) files, and how to build FreeBSD versions of YACC output (.c and .h) files. This is only different from your version by letting sys.mk rules run yacc(1), in one well defined way. These changes also resemble those that were before your WIP_GCC31 merge, and for which you already agreed by committing them. Not to say they fix a real bug in the -j case and fix CLEANFILES. You have repeatedly hounded me for quite a while about GCC. Since so much of my blood and sweat are not acceptable to you, I encourage you to become the GCC maintainer and do everything to your heart's desire. Sorry I was working on cross-platform building issues in the past that also needed some changes in GCC and Binutils. Sorry I sent you too many patches which fixed bugs or added features. Sorry you can't hold an exclusive lock on the whole FreeBSD. Is this really your sight at things? I'm amazed. What you call hounding would better be classified as a pure technical feedback including patches and asking related questions, and maintainer is excepted to deal with this load, either accepting patches or rejecting them (giving valid technical reasons). If you aren't capable of accepting useful critics (in the form of patches and answering questions), I think you should seriously reconsider whether you really want to continue be a MAINTAINER. (I say critics because that's how you probably take what I call feedback.) People are really making me regret that I sweated over GCC 3 to bring it into our tree for all of our architectures and to get many serious bugs fixed in the FSF CVS repository. What reward do you need for this? So that nobody reviews your commits, or looks to anything you are maintaining? You want the god mode in FreeBSD? Sorry but I'm affraid this is not possible, or FreeBSD should be renamed to ObrienBSD. GCC and Binutils are essential part of FreeBSD, sitting in its heart, and many other folks including me work on related issues, and apparently look to the work you're doing. From my first days in the project, I took it as a joint effort thing, in fact that's one of the reasons I agreed to become a committer, but behavior like you are demonstrating doesn't fold into this. What you don't seem to realize is that people like me and BDE _don't_ blame you but are just trying to help you do the work done. It's a real pita you see the things in a different light. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg38234/pgp0.pgp Description: PGP signature
Re: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
David O'Brien wrote: People are really making me regret that I sweated over GCC 3 to bring it into our tree for all of our architectures and to get many serious bugs fixed in the FSF CVS repository. Really? It must be in private email... from what I've seen, everything went incredibly smoothly -- moreso than could be reasonably expected. The only think I personally saw that was anywhere close to a real problem was the 96 byte boot bloat, which I think can be resolved with explicit aligns/#pragma pack(1), and disabling one of the speed vs. space optimizations (the instruction pipelining). The mailing lists have been, as far as I could tell, blissfully silent on the subject. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
On Fri, May 10, 2002 at 04:41:53PM -0700, David O'Brien wrote:
On Fri, May 10, 2002 at 06:04:27PM +0300, Ruslan Ermilov wrote:
Bmake bits for Gcc 3.1.
This also vanished my YACC building fixes and broke world while
attempting to build `cc1plus' in a cross-tools stage. The changes
below fix this and CLEANFILES.
These changes are wrong.
These changes have been verified to produce the same binaries
(except for cc1plus which is just broken without them), and
they are equivalent to what was already in -CURRENT before
your WIP_GCC31 merge commit.
RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc1/Makefile,v
...
-c-parse.c: c-parse.in
+c-parse.y: c-parse.in
sed -e /^ifobjc$$/,/^end ifobjc$$/d \
-e /^ifc$$/d \
-e /^end ifc$$/d \
- ${GCCDIR}/c-parse.in c-parse.y
- ${YACC} -o c-parse.c.in c-parse.y
- sed -e s/malloc/xmalloc/g \
+ -e s/malloc/xmalloc/g \
-e s/realloc/xrealloc/g \
- c-parse.c.in c-parse.c
+ ${.ALLSRC} ${.TARGET}
The malloc usage is in the Byacc output, not the input.
There's no difference, [b]yacc just copies C code blocks intact.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg38170/pgp0.pgp
Description: PGP signature
Re: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
On Sat, May 11, 2002 at 10:44:11AM +0300, Ruslan Ermilov wrote: On Fri, May 10, 2002 at 04:41:53PM -0700, David O'Brien wrote: On Fri, May 10, 2002 at 06:04:27PM +0300, Ruslan Ermilov wrote: Bmake bits for Gcc 3.1. This also vanished my YACC building fixes and broke world while attempting to build `cc1plus' in a cross-tools stage. The changes below fix this and CLEANFILES. These changes are wrong. These changes have been verified to produce the same binaries (except for cc1plus which is just broken without them), and they are equivalent to what was already in -CURRENT before your WIP_GCC31 merge commit. There is NO way you've bootstrapped GCC 3.1 using these patches. Remember a full bootstrap is a `make world ; make buildworld'. # cc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.1 20020509 (prerelease) # cd /usr/src/gnu/usr.bin/cc # make === cc_fbsd ... === cc_tools ... === cc_int ... cc -O -pipe -march=k6 -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\ -I/usr/obj/usr/src/gnu/usr.bin/for_ru/cc1/../cc_tools -I/usr/src/gnu/usr.bin/for_ru/cc1/../cc_tools -I/usr/src/gnu/usr.bin/for_ru/cc1/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/for_ru/cc1/../../../../contrib/gcc/config -I. -c c-parse.c c-parse.c:3047:29: attempt to use poisoned realloc c-parse.c:3048:16: attempt to use poisoned malloc c-parse.c:3053:31: attempt to use poisoned realloc c-parse.c:3054:18: attempt to use poisoned malloc *** Error code 1 I say again, the malloc usage is not in c-parse.in, it is in the parser driver produced by Byacc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
On Sat, May 11, 2002 at 10:44:11AM +0300, Ruslan Ermilov wrote: The malloc usage is in the Byacc output, not the input. There's no difference, [b]yacc just copies C code blocks intact. No. Byacc copies C code blocks from the input grammer intact. It also adds more C code to the output. See src/usr.bin/yacc/skeleton.c. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
Ruslan Ermilov wrote:
On Fri, May 10, 2002 at 04:41:53PM -0700, David O'Brien wrote:
On Fri, May 10, 2002 at 06:04:27PM +0300, Ruslan Ermilov wrote:
Bmake bits for Gcc 3.1.
=20
This also vanished my YACC building fixes and broke world while
attempting to build `cc1plus' in a cross-tools stage. The changes
below fix this and CLEANFILES.
=20
These changes are wrong.
=20
These changes have been verified to produce the same binaries
(except for cc1plus which is just broken without them), and
they are equivalent to what was already in -CURRENT before
your WIP_GCC31 merge commit.
I dont think you've tested them properly. They will not work.
RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc1/Makefile,v
...
-c-parse.c: c-parse.in
+c-parse.y: c-parse.in
sed -e /^ifobjc$$/,/^end ifobjc$$/d \
-e /^ifc$$/d \
-e /^end ifc$$/d \
- ${GCCDIR}/c-parse.in c-parse.y
- ${YACC} -o c-parse.c.in c-parse.y
- sed -e s/malloc/xmalloc/g \
+ -e s/malloc/xmalloc/g \
-e s/realloc/xrealloc/g \
- c-parse.c.in c-parse.c
+ ${.ALLSRC} ${.TARGET}
=20
The malloc usage is in the Byacc output, not the input.
=20
There's no difference, [b]yacc just copies C code blocks intact.
Do not forget the driver code. There are malloc/calloc calls in the byacc
generated c-parse.c.. There are no malloc/calloc calls in the c-parse.in
file (see for yourself). If you actually test this, you will get a failure
due to 'poisoned' malloc/calloc/etc calls.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
On Sat, May 11, 2002 at 01:00:27AM -0700, David O'Brien wrote:
On Sat, May 11, 2002 at 10:44:11AM +0300, Ruslan Ermilov wrote:
On Fri, May 10, 2002 at 04:41:53PM -0700, David O'Brien wrote:
On Fri, May 10, 2002 at 06:04:27PM +0300, Ruslan Ermilov wrote:
Bmake bits for Gcc 3.1.
This also vanished my YACC building fixes and broke world while
attempting to build `cc1plus' in a cross-tools stage. The changes
below fix this and CLEANFILES.
These changes are wrong.
These changes have been verified to produce the same binaries
(except for cc1plus which is just broken without them), and
they are equivalent to what was already in -CURRENT before
your WIP_GCC31 merge commit.
There is NO way you've bootstrapped GCC 3.1 using these patches.
Remember a full bootstrap is a `make world ; make buildworld'.
# cc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.1 20020509 (prerelease)
# cd /usr/src/gnu/usr.bin/cc
# make
=== cc_fbsd
...
=== cc_tools
...
=== cc_int
...
cc -O -pipe -march=k6 -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\
-I/usr/obj/usr/src/gnu/usr.bin/for_ru/cc1/../cc_tools
-I/usr/src/gnu/usr.bin/for_ru/cc1/../cc_tools
-I/usr/src/gnu/usr.bin/for_ru/cc1/../../../../contrib/gcc
-I/usr/src/gnu/usr.bin/for_ru/cc1/../../../../contrib/gcc/config -I.
-c c-parse.c
c-parse.c:3047:29: attempt to use poisoned realloc
c-parse.c:3048:16: attempt to use poisoned malloc
c-parse.c:3053:31: attempt to use poisoned realloc
c-parse.c:3054:18: attempt to use poisoned malloc
*** Error code 1
I say again, the malloc usage is not in c-parse.in, it is in the parser
driver produced by Byacc.
OK, now that you've explained it:
%%%
Index: cc1/Makefile
===
RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc1/Makefile,v
retrieving revision 1.26
diff -u -r1.26 Makefile
--- cc1/Makefile10 May 2002 08:54:45 - 1.26
+++ cc1/Makefile11 May 2002 09:33:44 -
@@ -2,7 +2,7 @@
.include ../Makefile.inc
-.PATH: ../cc_tools ${GCCDIR}
+.PATH: ${GCCDIR}
PROG= cc1
SRCS= main.c c-parse.c c-lang.c c-decl.c
@@ -17,17 +17,20 @@
#---
# C parser
-.ORDER: c-parse.c
-c-parse.c: c-parse.in
+
+YFLAGS=# don't need y.tab.h
+
+c-parse-in.y: c-parse.in
sed -e /^ifobjc$$/,/^end ifobjc$$/d \
-e /^ifc$$/d \
-e /^end ifc$$/d \
- ${GCCDIR}/c-parse.in c-parse.y
- ${YACC} -o c-parse.c.in c-parse.y
+ ${.ALLSRC} ${.TARGET}
+
+c-parse.c: c-parse-in.c
sed -e s/malloc/xmalloc/g \
-e s/realloc/xrealloc/g \
- c-parse.c.in c-parse.c
+ ${.ALLSRC} ${.TARGET}
-CLEANFILES+= c-parse.c c-parse.y # insurance
+CLEANFILES= c-parse-in.y c-parse-in.c c-parse.c
.include bsd.prog.mk
Index: cc1obj/Makefile
===
RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc1obj/Makefile,v
retrieving revision 1.20
diff -u -r1.20 Makefile
--- cc1obj/Makefile 10 May 2002 08:54:46 - 1.20
+++ cc1obj/Makefile 11 May 2002 09:33:44 -
@@ -2,7 +2,7 @@
.include ../Makefile.inc
-.PATH: ../cc_tools ${GCCDIR}/objc ${GCCDIR}
+.PATH: ${GCCDIR}/objc ${GCCDIR}
PROG= cc1obj
SRCS= objc-parse.c objc-act.c objc-lang.c main.c c-decl.c
@@ -17,18 +17,21 @@
#---
# objc parser
-.ORDER: objc-parse.c
-objc-parse.c: c-parse.in
+
+YFLAGS=# don't need y.tab.h
+
+objc-parse-in.y: c-parse.in
sed -e /^ifc$$/,/^end ifc$$/d \
-e /^ifobjc$$/d \
-e /^end ifobjc$$/d \
- ${GCCDIR}/c-parse.in objc-parse.y
- ${YACC} -o objc-parse.c.in objc-parse.y
+ ${.ALLSRC} ${.TARGET}
+
+objc-parse.c: objc-parse-in.c
sed -e s/malloc/xmalloc/g \
-e s/realloc/xrealloc/g \
- objc-parse.c.in objc-parse.c
+ ${.ALLSRC} ${.TARGET}
-CLEANFILES+= objc-parse.c objc-parse.y # insurance
+CLEANFILES= objc-parse-in.y objc-parse-in.c objc-parse.c
#---
Index: cc1plus/Makefile
===
RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc1plus/Makefile,v
retrieving revision 1.27
diff -u -r1.27 Makefile
--- cc1plus/Makefile10 May 2002 08:54:46 - 1.27
+++ cc1plus/Makefile11 May 2002 09:33:44 -
@@ -5,7 +5,7 @@
.PATH: ${GCCDIR}/cp ${GCCDIR}
PROG= cc1plus
-SRCS= parse.y cfns.h
+SRCS= parse.c parse.h cfns.h
SRCS+= main.c cp-lang.c
SRCS+= call.c class.c cvt.c decl.c decl2.c error.c except.c expr.c \
friend.c init.c lex.c mangle.c
Re: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
On Sat, May 11, 2002 at 12:35:38PM +0300, Ruslan Ermilov wrote: I say again, the malloc usage is not in c-parse.in, it is in the parser driver produced by Byacc. OK, now that you've explained it: I'll look this patch over carefully, but at first glance it all seems like stylistic changes. Does it fix a bug, or you just don't like how I did things? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
On Fri, May 10, 2002 at 01:54:50AM -0700, David E. O'Brien wrote:
obrien 2002/05/10 01:54:50 PDT
Modified files:
gnu/lib/csu Makefile
gnu/lib/libgcc Makefile
gnu/lib/libibertyMakefile
gnu/lib/libobjc Makefile
gnu/lib/libstdc++Makefile config.h
gnu/lib/libsupc++Makefile
gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc
Makefile.tgt
gnu/usr.bin/cc/c++ Makefile
gnu/usr.bin/cc/c++filt Makefile
gnu/usr.bin/cc/ccMakefile
gnu/usr.bin/cc/cc1 Makefile
gnu/usr.bin/cc/cc1obj Makefile
gnu/usr.bin/cc/cc1plus Makefile
gnu/usr.bin/cc/cc_drv Makefile
gnu/usr.bin/cc/cc_fbsd Makefile
gnu/usr.bin/cc/cc_int Makefile
gnu/usr.bin/cc/cc_tools Makefile auto-host.h freebsd-native.h
gnu/usr.bin/cc/cccp Makefile
gnu/usr.bin/cc/collect2 Makefile
gnu/usr.bin/cc/cpp Makefile
gnu/usr.bin/cc/cpp0 Makefile
gnu/usr.bin/cc/doc Makefile
gnu/usr.bin/cc/f77 Makefile
gnu/usr.bin/cc/f771 Makefile
gnu/usr.bin/cc/f77doc Makefile
gnu/usr.bin/cc/gcov Makefile
gnu/usr.bin/cc/protoize Makefile
gnu/usr.bin/cc/tradcpp0 Makefile
Log:
Bmake bits for Gcc 3.1.
Partially made possible by: [EMAIL PROTECTED]
This also vanished my YACC building fixes and broke world while
attempting to build `cc1plus' in a cross-tools stage. The changes
below fix this and CLEANFILES.
(David, I'm copying -current so that others may benefit from this
patch while you're asleep.)
%%%
Index: cc1/Makefile
===
RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc1/Makefile,v
retrieving revision 1.26
diff -u -r1.26 Makefile
--- cc1/Makefile10 May 2002 08:54:45 - 1.26
+++ cc1/Makefile10 May 2002 14:54:51 -
@@ -2,10 +2,10 @@
.include ../Makefile.inc
-.PATH: ../cc_tools ${GCCDIR}
+.PATH: ${GCCDIR}
PROG= cc1
-SRCS= main.c c-parse.c c-lang.c c-decl.c
+SRCS= main.c c-parse.y c-lang.c c-decl.c
BINDIR=/usr/libexec
NOMAN= 1
NOSHARED?=yes
@@ -17,17 +17,14 @@
#---
# C parser
-.ORDER: c-parse.c
-c-parse.c: c-parse.in
+c-parse.y: c-parse.in
sed -e /^ifobjc$$/,/^end ifobjc$$/d \
-e /^ifc$$/d \
-e /^end ifc$$/d \
- ${GCCDIR}/c-parse.in c-parse.y
- ${YACC} -o c-parse.c.in c-parse.y
- sed -e s/malloc/xmalloc/g \
+ -e s/malloc/xmalloc/g \
-e s/realloc/xrealloc/g \
- c-parse.c.in c-parse.c
+ ${.ALLSRC} ${.TARGET}
-CLEANFILES+= c-parse.c c-parse.y # insurance
+CLEANFILES= c-parse.y
.include bsd.prog.mk
Index: cc1obj/Makefile
===
RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc1obj/Makefile,v
retrieving revision 1.20
diff -u -r1.20 Makefile
--- cc1obj/Makefile 10 May 2002 08:54:46 - 1.20
+++ cc1obj/Makefile 10 May 2002 14:54:51 -
@@ -2,10 +2,10 @@
.include ../Makefile.inc
-.PATH: ../cc_tools ${GCCDIR}/objc ${GCCDIR}
+.PATH: ${GCCDIR}/objc ${GCCDIR}
PROG= cc1obj
-SRCS= objc-parse.c objc-act.c objc-lang.c main.c c-decl.c
+SRCS= objc-parse.y objc-act.c objc-lang.c main.c c-decl.c
BINDIR=/usr/libexec
NOMAN= 1
NOSHARED?=yes
@@ -17,18 +17,16 @@
#---
# objc parser
-.ORDER: objc-parse.c
-objc-parse.c: c-parse.in
+
+objc-parse.y: c-parse.in
sed -e /^ifc$$/,/^end ifc$$/d \
-e /^ifobjc$$/d \
-e /^end ifobjc$$/d \
- ${GCCDIR}/c-parse.in objc-parse.y
- ${YACC} -o objc-parse.c.in objc-parse.y
- sed -e s/malloc/xmalloc/g \
+ -e s/malloc/xmalloc/g \
-e s/realloc/xrealloc/g \
- objc-parse.c.in objc-parse.c
+ ${.ALLSRC} ${.TARGET}
-CLEANFILES+= objc-parse.c objc-parse.y # insurance
+CLEANFILES+= objc-parse.y
#---
Index: cc1plus/Makefile
===
RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc1plus/Makefile,v
retrieving revision 1.27
diff -u -r1.27 Makefile
--- cc1plus/Makefile10 May 2002 08:54:46 - 1.27
+++ cc1plus/Makefile10 May 2002 14:54:51 -
@@ -5,7 +5,7 @@
.PATH: ${GCCDIR}/cp ${GCCDIR}
PROG= cc1plus
-SRCS= parse.y cfns.h
+SRCS= parse.y y.tab.h parse.h cfns.h
SRCS+= main.c cp-lang.c
SRCS+= call.c class.c cvt.c decl.c decl2.c error.c except.c expr.c \
friend.c init.c lex.c mangle.c method.c pt.c ptree.c repo.c rtti.c \
@@ -20,21 +20,19 @@
DPADD+=${LIBCC_INT}
LDADD+=${LIBCC_INT}
-CLEANFILES+= parse.c parse.h y.tab.c y.tab.h cfns.h
+CLEANFILES= parse.y parse.h
Re: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
On Fri, May 10, 2002 at 06:04:27PM +0300, Ruslan Ermilov wrote:
Bmake bits for Gcc 3.1.
This also vanished my YACC building fixes and broke world while
attempting to build `cc1plus' in a cross-tools stage. The changes
below fix this and CLEANFILES.
These changes are wrong.
RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc1/Makefile,v
...
-c-parse.c: c-parse.in
+c-parse.y: c-parse.in
sed -e /^ifobjc$$/,/^end ifobjc$$/d \
-e /^ifc$$/d \
-e /^end ifc$$/d \
- ${GCCDIR}/c-parse.in c-parse.y
- ${YACC} -o c-parse.c.in c-parse.y
- sed -e s/malloc/xmalloc/g \
+ -e s/malloc/xmalloc/g \
-e s/realloc/xrealloc/g \
- c-parse.c.in c-parse.c
+ ${.ALLSRC} ${.TARGET}
The malloc usage is in the Byacc output, not the input.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: libgcc
On Sat, Apr 15, 2000 at 11:26:44AM +0400, Ilmar S. Habibulin wrote: When does subj links with the executables? When using the ``cc'' or ``c++'' front ends libgcc.a is automatically linked in. Use ``cc -v'' to see this happening. I have many problems linking new KDE, because it uses service function from this library, and i suspect that libgcc.a is not linked by default. :( Should it or i have to point it (?) by hands? Adding "CFLAGS+= -v" to your /etc/make.conf might help you in finding the problem. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libgcc
On Sat, 15 Apr 2000, David O'Brien wrote: On Sat, Apr 15, 2000 at 11:26:44AM +0400, Ilmar S. Habibulin wrote: When does subj links with the executables? When using the ``cc'' or ``c++'' front ends libgcc.a is automatically linked in. Use ``cc -v'' to see this happening. You mean to look at cc vertion? Yes, it is just gcc frontend or hardlink(i suppose). I have many problems linking new KDE, because it uses service function from this library, and i suspect that libgcc.a is not linked by default. :( Should it or i have to point it (?) by hands? Adding "CFLAGS+= -v" to your /etc/make.conf might help you in finding the problem. libtool prints out commands executed. And this autoconf/automake/configure stuff uses gcc and g++. I set CC,CXX and CPP variables. Now everything seem to work. Thank you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
** HEADS UP ** cvs commit: src/gnu/usr.bin/cc/cc_tools Makefile src/gnu/lib/libgcc Makefile src/contrib/gcc/config freebsd.h src/contrib/gcc/config/i386 freebsd.h src/contrib/gcc/config/alpha freebsd.h
This commit -- changing much of the configuration of GCC on a FreeBSD
host, has the potential to wreck havoc. One typo in these files can
render your compiler dead. I have tested these changes on both i386 and
DEC Alpha. However your environment may tickle an area of the
configuration mine didn't.
So if you are some what cautious, you might want to hold off a day or two
before your next buildworld.
- Forwarded message from "David E. O'Brien" [EMAIL PROTECTED] -
Modified files:
gnu/usr.bin/cc/cc_tools Makefile
gnu/lib/libgcc Makefile
contrib/gcc/config freebsd.h
contrib/gcc/config/i386 freebsd.h
contrib/gcc/config/alpha freebsd.h
Log:
Clean up the FreeBSD configuration files -- includes removing the usage
of svr4.h on the i386, and moving all the shared arch neutral bits into
the FreeBSD general config header.
- End forwarded message -
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: breakage in libgcc?
Sounds like you havn't -current. In message [EMAIL PROTECTED], Mike Smith writes: just cvsupped Your system; I just finished a world not five minutes ago. Suspect the usual. echo '#include xm-freebsd.h' config.h echo '#include "i386/xm-i386.h"' tconfig.h echo '#include "i386/i386.h"' tm.h echo '#include "i386/att.h"' tm.h echo '#include "i386/freebsd.h"' tm.h echo '#include "i386/perform.h"' tm.h cc -c -O -pipe -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC -I/usr/obj/usr/src/tmp/usr/include -DL_mulsi3 -o _mulsi3.o /usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c *** Signal 12 Stop in /usr/src/gnu/lib/libgcc. *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: breakage in libgcc?
*** Signal 12 Stop in /usr/src/gnu/lib/libgcc. *** Error code 1 Suspect that you need a newer kernel before you can build the world. had to o make new config o make new kernel o reboot o make world o ... must have been an exciting time in current while i was on the road the last three weeks. :-) randy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: breakage in libgcc?
Randy Bush wrote: just cvsupped echo '#include xm-freebsd.h' config.h echo '#include "i386/xm-i386.h"' tconfig.h echo '#include "i386/i386.h"' tm.h echo '#include "i386/att.h"' tm.h echo '#include "i386/freebsd.h"' tm.h echo '#include "i386/perform.h"' tm.h cc -c -O -pipe -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config -I/ usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC -I/usr/obj/usr/src/tmp/usr/include -DL_mulsi3 -o _mulsi3.o /usr/src/gnu/lib /libgcc/../../../contrib/egcs/gcc/libgcc1.c *** Signal 12 Stop in /usr/src/gnu/lib/libgcc. *** Error code 1 You need to build a new kernel *before* you 'make world'. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
breakage in libgcc?
just cvsupped echo '#include xm-freebsd.h' config.h echo '#include "i386/xm-i386.h"' tconfig.h echo '#include "i386/i386.h"' tm.h echo '#include "i386/att.h"' tm.h echo '#include "i386/freebsd.h"' tm.h echo '#include "i386/perform.h"' tm.h cc -c -O -pipe -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC -I/usr/obj/usr/src/tmp/usr/include -DL_mulsi3 -o _mulsi3.o /usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c *** Signal 12 Stop in /usr/src/gnu/lib/libgcc. *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: breakage in libgcc?
just cvsupped Your system; I just finished a world not five minutes ago. Suspect the usual. echo '#include xm-freebsd.h' config.h echo '#include "i386/xm-i386.h"' tconfig.h echo '#include "i386/i386.h"' tm.h echo '#include "i386/att.h"' tm.h echo '#include "i386/freebsd.h"' tm.h echo '#include "i386/perform.h"' tm.h cc -c -O -pipe -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc -I. -fexceptions -DIN_GCC -I/usr/obj/usr/src/tmp/usr/include -DL_mulsi3 -o _mulsi3.o /usr/src/gnu/lib/libgcc/../../../contrib/egcs/gcc/libgcc1.c *** Signal 12 Stop in /usr/src/gnu/lib/libgcc. *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: breakage in libgcc?
just cvsupped Your system; I just finished a world not five minutes ago. Suspect the usual. ok. doing a make clean now randy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: breakage in libgcc?
On Sat, 9 Oct 1999, Mike Smith wrote: just cvsupped Your system; I just finished a world not five minutes ago. Suspect the usual. Suspect that you need a newer kernel before you can build the world. *** Signal 12 Stop in /usr/src/gnu/lib/libgcc. *** Error code 1 -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
libgcc
I've got an egcs related question here. If it wasn't for the linking, this would be a ports question, but bear with me, you'll see. Anyhow, I was trying to get sp to work, as I continue checking into xml and xsl, so I used the /usr/ports/textproc/sp port. It dies in several places, because it's unable to find the symbol set_new_handler. This guy is defined in new.h (which points towards new, which has the very simple code for it). The problem is, the code for it is stuffed into libgcc.a. I thought libgcc was being deprecated, isn't that so? That only libstdc++ was going to be needed? This is a pretty well needed function, so I'm somewhat confused, and hope that some other C++ expert can explain what's happening under egcs these days, with respect to libgcc. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: libgcc
In article pine.bsf.4.10.9905291806500.375-100...@picnic.mat.net, Chuck Robey chu...@picnic.mat.net wrote: I thought libgcc was being deprecated, isn't that so? That only libstdc++ was going to be needed? No, I think you're confusing libgcc with libg++. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: libgcc
On Sat, 29 May 1999, John Polstra wrote: In article pine.bsf.4.10.9905291806500.375-100...@picnic.mat.net, Chuck Robey chu...@picnic.mat.net wrote: I thought libgcc was being deprecated, isn't that so? That only libstdc++ was going to be needed? No, I think you're confusing libgcc with libg++. Yeah, guess you're right, I was. OK, thanks. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: thread-safe libgcc
On 11-Apr-99 Luoqi Chen wrote: For threaded applications to work correctly, we need a thread-safe version of libgcc. It is straight forward to build: define _PTHREADS in CFLAGS. We can have both versions just like libc and libc_r, and use the thread-safe version when linking threaded applications. If no one objects, I will add it to our tree and make necessary changes to gcc to use it. By all means, please do. Since GTk+ or Gnome likes threads as well, and a lot more Linux apps do as well... --- Jeroen Ruigrok van der Werven http://www.freebsdzine.org asmodai(at)wxs.nlThe idea does not replace the work... Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: Powered by Knowledge Know-how http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
thread-safe libgcc
For threaded applications to work correctly, we need a thread-safe version of libgcc. It is straight forward to build: define _PTHREADS in CFLAGS. We can have both versions just like libc and libc_r, and use the thread-safe version when linking threaded applications. If no one objects, I will add it to our tree and make necessary changes to gcc to use it. -lq To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvsupped libgcc grief
On Sun, 04 Apr 1999 12:48:04 GMT, George Cox wrote: cc: Internal compiler error: program cc1 got fatal signal 11 [...] FreeBSD-CURRENT -- Because I'm worth it. How did you find out about CURRENT without finding out about the FAQ? Please read section 4 of the FreeBSD FAQ, available online at http://www.freebsd.org/FAQ/FAQ.html, paying particular attention to the question My programs occasionally die with ``Signal 11'' errors.. Then see if you get the same error in the same place consistently with a clean obj tree. My money's on dud hardware. :-( Later, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
cvsupped libgcc grief
Well, the troubles continue, after much buggering around with an incorrectly linked cc1 binary, cooked up from I don't know where I ask Is anyone else seeing this kind of error on make buildworld'ing In file included from /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/i386/freebsd.h:28, from tm.h:1, from /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/i386/xm-i386.h:43, from /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/i386/xm-freebsd.h:3, from config.h:1, from /usr/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc1.c:35: /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/i386/i386.h:530: syntax error before `,' /usr/src/gnu/lib/libgcc/../../../contrib/gcc/config/i386/i386.h:540: warning: no semicolon at end of struct or union cc: Internal compiler error: program cc1 got fatal signal 11 -- [gjvc] FreeBSD-CURRENT -- Because I'm worth it. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
