-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It looks like the stack somehow mangled before entering strlen()? I'm
somehow confused with this...
Cheers,
- --
Xin LI http://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG
On Tue, 23 Mar 2010 06:40, alexbestms@ wrote:
Pegasus Mc Cleaft schrieb am 2010-03-23:
-Original Message-
2. i wasn't able to reproduce your `make -V MACHINE_CPU
-DCPUTYPE=native`
examples. for me `make` prints the same no matter what CPUTYPE is
set to:
otaku% make -V MACHINE_CPU -D
Scot Hetzel schrieb am 2010-03-23:
> On Tue, Mar 23, 2010 at 4:34 AM, Alexander Best
> wrote:
> > i don't think conf/112997 and the issue where gcc segfaults are
> > directly
> > related to each other:
> > 1. if CPUTYPE is set to 'native' your patch uses `gcc -v -x c -E
> >-mtune=native
> > /
On Tue, Mar 23, 2010 at 11:19 AM, Scot Hetzel wrote:
> On Tue, Mar 23, 2010 at 4:34 AM, Alexander Best wrote:
>> i don't think conf/112997 and the issue where gcc segfaults are directly
>> related to each other:
>>
>> 1. if CPUTYPE is set to 'native' your patch uses `gcc -v -x c -E
>> -mtune=nat
On Tue, Mar 23, 2010 at 4:34 AM, Alexander Best wrote:
> i don't think conf/112997 and the issue where gcc segfaults are directly
> related to each other:
>
> 1. if CPUTYPE is set to 'native' your patch uses `gcc -v -x c -E -mtune=native
> /dev/null -o /dev/null 2>&1 | grep mtune | sed -e 's/.*mtu
Pegasus Mc Cleaft schrieb am 2010-03-23:
> -Original Message-
> >2. i wasn't able to reproduce your `make -V MACHINE_CPU
> >-DCPUTYPE=native`
> >examples. for me `make` prints the same no matter what CPUTYPE is
> >set to:
> >otaku% make -V MACHINE_CPU -DCPUTYPE=native
> >amd64 sse2 sse
> >
-Original Message-
From: Pegasus Mc Cleaft [mailto:k...@mthelicon.com]
Sent: 23 March 2010 09:57
To: 'Alexander Best'
Subject: RE: build failures after stdlib update
-Original Message-
>2. i wasn't able to reproduce your `make -V MACHINE_CPU -DCPUTYPE=native`
i don't think conf/112997 and the issue where gcc segfaults are directly
related to each other:
1. if CPUTYPE is set to 'native' your patch uses `gcc -v -x c -E -mtune=native
/dev/null -o /dev/null 2>&1 | grep mtune | sed -e 's/.*mtune=//'` to determine
gcc's idea of the appropriate -mtune value.
On Sun, Mar 21, 2010 at 7:29 PM, jhell wrote:
> Native is equal to CPUTYPE not being defined right ?
>
Built into GCC is the ability to auto-detect the CPUTYPE when
-mtune=native, if you run this command GCC will tell ouput your
processor type:
gcc -v -x c -E -mtune=native /dev/null -o /dev/null
Andriy Gapon schrieb am 2010-03-22:
> on 22/03/2010 00:12 Alexander Best said the following:
> > Andriy Gapon schrieb am 2010-03-21:
> >> on 21/03/2010 23:11 Alexander Best said the following:
> >>> *hehe* that makes more sense. well i already sent you lp.
> >>> unfortunately str is
> >>> not avail
on 22/03/2010 00:12 Alexander Best said the following:
> Andriy Gapon schrieb am 2010-03-21:
>> on 21/03/2010 23:11 Alexander Best said the following:
>>> *hehe* that makes more sense. well i already sent you lp.
>>> unfortunately str is
>>> not available to gdb:
>
>>> (gdb) print str
>>> Variable
On 2010-03-21 22:20, Garrett Cooper wrote:
From gcc(1):
-s Remove all symbol table and relocation information from the exe-
cutable.
This is more or less the same as running strip(1) over the produced
executables. Usually one uses it for non-debug builds.
That seems a bit
On Sun, 21 Mar 2010 07:00, alexbestms@ wrote:
Garrett Cooper schrieb am 2010-03-21:
On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best
wrote:
ok. i think i finally solved this riddle. the cause for the problem
seems to
have been my CPUTYPE in /etc/make.conf. it is set to 'native'.
actually i've
Andriy Gapon schrieb am 2010-03-21:
> on 21/03/2010 23:11 Alexander Best said the following:
> > *hehe* that makes more sense. well i already sent you lp.
> > unfortunately str is
> > not available to gdb:
> > (gdb) print str
> > Variable "str" is not available.
> In cases like this sometimes the
on 21/03/2010 23:11 Alexander Best said the following:
> *hehe* that makes more sense. well i already sent you lp. unfortunately str is
> not available to gdb:
>
> (gdb) print str
> Variable "str" is not available.
In cases like this sometimes the argument is still available for examination as
a
On Sun, Mar 21, 2010 at 2:11 PM, Alexander Best wrote:
> Andriy Gapon schrieb am 2010-03-21:
>> on 21/03/2010 20:46 Alexander Best said the following:
>> > Andriy Gapon schrieb am 2010-03-21:
>> >> on 21/03/2010 14:53 Alexander Best said the following:
>> >>> *lol* sorry. ;)
>
>> >> No worries.
>>
On Sun, Mar 21, 2010 at 8:35 AM, Dimitry Andric wrote:
> On 2010-03-21 14:08, Gary Jennejohn wrote:
CPUTYPE=native
CFLAGS=-O2 -fno-strict-aliasing -pipe -s
btw: what's the -s switch doing?
>>>
>>> It "silences" make. See the man page. It's useful because basically
>>> on
Andriy Gapon schrieb am 2010-03-21:
> on 21/03/2010 20:46 Alexander Best said the following:
> > Andriy Gapon schrieb am 2010-03-21:
> >> on 21/03/2010 14:53 Alexander Best said the following:
> >>> *lol* sorry. ;)
> >> No worries.
> >> BTW, when that rash happens, are you able to examine the core
on 21/03/2010 20:46 Alexander Best said the following:
> Andriy Gapon schrieb am 2010-03-21:
>> on 21/03/2010 14:53 Alexander Best said the following:
>>> *lol* sorry. ;)
>
>> No worries.
>> BTW, when that rash happens, are you able to examine the core with
>> gdb?
>> Is it possible to examine val
Andriy Gapon schrieb am 2010-03-21:
> on 21/03/2010 14:53 Alexander Best said the following:
> > *lol* sorry. ;)
> No worries.
> BTW, when that rash happens, are you able to examine the core with
> gdb?
> Is it possible to examine values of 's' and 'p' in strlen?
'p' is not available. i guess bec
On 2010-03-21 14:08, Gary Jennejohn wrote:
CPUTYPE=native
CFLAGS=-O2 -fno-strict-aliasing -pipe -s
btw: what's the -s switch doing?
It "silences" make. See the man page. It's useful because basically only
errors are emitted.
Oops. That's wrong. I got confused. I'd like to know that myse
on 21/03/2010 14:53 Alexander Best said the following:
> *lol* sorry. ;)
No worries.
BTW, when that rash happens, are you able to examine the core with gdb?
Is it possible to examine values of 's' and 'p' in strlen?
--
Andriy Gapon
___
freebsd-current@
On Sun, 21 Mar 2010 14:03:04 +0100
Gary Jennejohn wrote:
> On Sun, 21 Mar 2010 13:43:52 +0100 (CET)
> Alexander Best wrote:
>
> > Pegasus Mc Cleaft schrieb am 2010-03-21:
> > > > > it would be nice if people with arch i386 and amd64 could try to
> > > > > reproduce this (i believe the other arc
On Sun, 21 Mar 2010 13:43:52 +0100 (CET)
Alexander Best wrote:
> Pegasus Mc Cleaft schrieb am 2010-03-21:
> > > > it would be nice if people with arch i386 and amd64 could try to
> > > > reproduce this (i believe the other archs don't support
> > > > CPUTYPE=native).
> > > > again the easiest way
Andriy Gapon schrieb am 2010-03-21:
> on 21/03/2010 14:35 Alexander Best said the following:
> > Andriy Gapon schrieb am 2010-03-21:
> >> on 21/03/2010 13:43 Garrett Cooper said the following:
> >>> Works for me *shrugs*:
> >>> $ gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1
> >>> Usin
on 21/03/2010 14:35 Alexander Best said the following:
> Andriy Gapon schrieb am 2010-03-21:
>> on 21/03/2010 13:43 Garrett Cooper said the following:
>
>>> Works for me *shrugs*:
>
>>> $ gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1
>>> Using built-in specs.
>>> Target: amd64-undermyd
Pegasus Mc Cleaft schrieb am 2010-03-21:
> > > it would be nice if people with arch i386 and amd64 could try to
> > > reproduce this (i believe the other archs don't support
> > > CPUTYPE=native).
> > > again the easiest way to trigger this (you don't need to edit
> > > your
> > > /etc/make.conf fo
> > it would be nice if people with arch i386 and amd64 could try to
> > reproduce this (i believe the other archs don't support CPUTYPE=native).
> > again the easiest way to trigger this (you don't need to edit your
> > /etc/make.conf for this) should be running:
> >
> > gcc -v -x c -E -mtune=nati
Garrett Cooper schrieb am 2010-03-21:
> On Sun, Mar 21, 2010 at 4:00 AM, Alexander Best
> wrote:
> > Garrett Cooper schrieb am 2010-03-21:
> >> On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best
> >>
> >> wrote:
> >> > ok. i think i finally solved this riddle. the cause for the
> >> > problem
> >> >
on 21/03/2010 13:43 Garrett Cooper said the following:
>
> Works for me *shrugs*:
>
> $ gcc -v -x c -E -mtune=native /dev/null -o /dev/null 2>&1
> Using built-in specs.
> Target: amd64-undermydesk-freebsd
> Configured with: FreeBSD/amd64 system compiler
> Thread model: posix
> gcc version 4.2.1 2
On Sun, Mar 21, 2010 at 4:00 AM, Alexander Best wrote:
> Garrett Cooper schrieb am 2010-03-21:
>> On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best
>> wrote:
>> > ok. i think i finally solved this riddle. the cause for the problem
>> > seems to
>> > have been my CPUTYPE in /etc/make.conf. it is set
Garrett Cooper schrieb am 2010-03-21:
> On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best
> wrote:
> > ok. i think i finally solved this riddle. the cause for the problem
> > seems to
> > have been my CPUTYPE in /etc/make.conf. it is set to 'native'.
> > actually i've
> > been using the 'native' key
On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best wrote:
> ok. i think i finally solved this riddle. the cause for the problem seems to
> have been my CPUTYPE in /etc/make.conf. it is set to 'native'. actually i've
> been using the 'native' keyword for years now and never had any problems with
> it,
on 21/03/2010 02:55 Alexander Best said the following:
> ok. i think i finally solved this riddle. the cause for the problem seems to
> have been my CPUTYPE in /etc/make.conf. it is set to 'native'. actually i've
> been using the 'native' keyword for years now and never had any problems with
> it,
ok. i think i finally solved this riddle. the cause for the problem seems to
have been my CPUTYPE in /etc/make.conf. it is set to 'native'. actually i've
been using the 'native' keyword for years now and never had any problems with
it, but it seems a recent commit broke 'native' as CPUTYPE. for me
i still haven't been able to do a buildworld without cc segfaulting. :(
if i repeat the cc operation that segfaulted during buildworld with cc under
/usr/bin everything works fine. the segfault only occurs during buildworld
with the bootstrapped version of cc under /usr/ob/usr/src/tmp/usr/bin/cc.
On Wednesday 17 March 2010 02:22:48 Alexander Best wrote:
> so is there no way to fix this? this is what i've tried and still the
> problem exists:
Alex,
I finally got my machine all back up and running. I'll tell you what I
did and maybe it might help your situation. The only differen
On Wednesday 17 March 2010 02:22:48 Alexander Best wrote:
> so is there no way to fix this? this is what i've tried and still the
> problem exists:
One thing I am trying (and I have no idea if it will work yet) is
seeing
if replacing the /usr/lib/libc* archives with a working set from a
so is there no way to fix this? this is what i've tried and still the problem
exists:
1. backup /etc
2. `wget -r
ftp://ftp.allbsd.org/pub/FreeBSD-snapshots/amd64/9.0-HEAD-20100222-JPSNAP/ftp/base/`
(this shnapshot shouldn't contain the libc bug)
3. then i ran the install.sh script in that director
On 2010-Mar-13 18:31:19 +, Pegasus Mc Cleaft wrote:
> I am not able to build the latest world (I havent tried kernel yet).
>Whenever I start gengtype dies with a signal 10.
One problem is that much of the toolchain is statically linked so once
you have a corrupted libc function, the t
hi there,
i'm having similar issues with libc. while doing buildworld i got this
segfault:
>>> stage 4.2: building libraries
--
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64
CPUTYPE=native GROFF_BIN_PATH=/us
> >
> >Can anyone give me advice on how to track this problem down or fix
> > it? I suspect I still have a lib that still trying to use the broken
> > libc.so.7 or something else depended on it, but I am not sure..
>
> Some of the items in this commit may be causing the bad juju
> you'
On Sat, Mar 13, 2010 at 10:31 AM, Pegasus Mc Cleaft wrote:
> Hello Current,
>
> I am wondering if someone could help me please.
>
> I built the 9.0-current kernel and world while there was still a bug in
> the updated strlen(). Unfortunately this rendered the machine unbootable as
>
Hello Current,
I am wondering if someone could help me please.
I built the 9.0-current kernel and world while there was still a bug in
the updated strlen(). Unfortunately this rendered the machine unbootable as
gptzfsloader crashed and would just echo an endless stream of spac
44 matches
Mail list logo
