This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Wierd sparc sunos4 intermittant SEGV during bootstrap in libgcc2.a
- To: wilson at cygnus dot com
- Subject: Re: Wierd sparc sunos4 intermittant SEGV during bootstrap in libgcc2.a
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Sat, 4 Mar 2000 10:27:16 -0500 (EST)
- Cc: davem at redhat dot com, egcs-bugs at egcs dot cygnus dot com, rth at cygnus dot com
> From: Jim Wilson <wilson@cygnus.com>
>
> I haven't tried any FSF gcc sources on SunOS4 systems here.
>
> However, the Cygnus source tree has been failing on SunOS4 systems
> since our last merge from the FSF gcc source tree. I tracked the
> problem down to a problem with the Sun C library strncmp function
> reading past the end of strings. Now that gcc uses mmap, and we've
> got mmap allocating disjoint memory regions, we end up with many
> places where mapped memory ends. Formerly, there was only one place
> where mapped memory ended, at the end of the heap. When you have lots
> of places where memory ends, there is a much higher change that a
> string will end up against a place where memory ends, and if that
> happens, then you can get a segfault. These failures I saw were
> repeatable though.
>
> Disabling use of mmap is one of the first things I'd try if I had
> problems with SunOS4.
>
> Jim
Okay, I disabled the "mmap anywhere" test so that gcc-page.c used
valloc, and I also forcibly added my own strncmp.o to libiberty and
relinked stage2. When I tried rebuilding libgcc.a with that stage, I
got the same error.
So my question remains, is it possible that the flush instruction
issue has resurfaced? IIRC the sun4m arch is particularly vulnerable
to this. Does anyone else have a sun4m on which they can report
sunos4 bootstrap results?
Thanks,
--Kaveh
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Qwest Internet Solutions