Re: gcc
Peter was working on it, but I strongly suspect he won't have time to even think about this in the very near future Personally, I'm slowly working on putting the FreeBSD GCC changes into EGCS 1.1.1 so it can compile our sources. I've got the compiler contribed and am working on the contrib of libstdc++. I will share my local CVS tree with anyone that wants to help out. It would probably be cool to find out what the last set of issues he identified and/or fixed with this was though. Agreed. Peter is being quite quiet on this subject. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
On Sat, 27 Feb 1999, Jordan K. Hubbard wrote: I for one would love to see 2.8.1 or newer in the tree for my own, selfish reasons. Many ports (new architectures) would benefit from this. Is that to say that you prefer it over egcs 1.1.1? If so, why? I have found egcs to be slightly better at C++ code (for my own projects anyway). I believe that it may produce better code too but I don't have any real evidence. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
David O'Brien wrote: Peter was working on it, but I strongly suspect he won't have time to even think about this in the very near future Personally, I'm slowly working on putting the FreeBSD GCC changes into EGCS 1.1.1 so it can compile our sources. Hmm... Does it not make more sense to slowly remove the FreeBSD'ism that require that we futz with the compiler? I've got the compiler contribed and am working on the contrib of libstdc++. I will share my local CVS tree with anyone that wants to help out. Me, please! M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
Hmm... Does it not make more sense to slowly remove the FreeBSD'ism that require that we futz with the compiler? I don't think bde, et. al. is going to let -fformat-extensions go away. :-) -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
David O'Brien wrote: Hmm... Does it not make more sense to slowly remove the FreeBSD'ism that require that we futz with the compiler? I don't think bde, et. al. is going to let -fformat-extensions go away. :-) Then can't we get that put into mainstream gcc/egcs? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
On Sat, 27 Feb 1999, Jordan K. Hubbard wrote: I for one would love to see 2.8.1 or newer in the tree for my own, selfish reasons. Many ports (new architectures) would benefit from this. Is that to say that you prefer it over egcs 1.1.1? If so, why? I was a little surprised at the egcs thing myself. While I (along with probably everyone else) thinks that egcs is more advanced, it's also had the bugs that go along with being leading edge. Since FreeBSD's extremely conservative attitude towards changing our compiler is very nearly legendary, well, to be willing to jump towards the bleeding edge suprised me. If there really exists the political will to move us to egcs, this might be a good thing. The code is very definitely better, and moving us towards egcs will make a later upgrade to an even newer egcs somewhat easier, perhaps. More importantly, it's going to make the egcs writers take notice, and have a bit more receptive attitude towards accepting patches from us for the FreeBSD port ... possibly REALLY easing the upgrade path. My own personal experience is that the egcs people read and react to trouble reports ... I've sent them in to the gcc authors in the past, but never seen any changes from them, like I did from egcs. +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | 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: gcc
Hmm... Does it not make more sense to slowly remove the FreeBSD'ism that require that we futz with the compiler? I don't think bde, et. al. is going to let -fformat-extensions go away. :-) Then can't we get that put into mainstream gcc/egcs? Because extensions are extensions of the mainstream gcc/egcs, by definition. Format extensions that belong in the mainstream version aren't controlled by -fformat-extensions. E.g., the __printf0__ attribute. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
tail /proc/map/*
tail(1) assumes that mmap(2) works on works on regular files. mmap(2) on the irregular regular files /proc/*/map returns success but doesn't work. The first access to the mmapped memory usually causes the kernel to printf messages like the following: vnode_pager: *** WARNING *** stale FS getpages No strategy for buffer at 0xf12828e8 : 0xf3877800: type VREG, usecount 4, writecount 0, refcount 0, flags (VOBJBUF) tag VT_PROCFS, type 11, pid 591, mode 124, flags 0 : 0xf3877800: type VREG, usecount 4, writecount 0, refcount 0, flags (VOBJBUF) tag VT_PROCFS, type 11, pid 591, mode 124, flags 0 vnode_pager_getpages: I/O read error vm_fault: pager read error, pid 2023 (tail) pid 2023 (tail), uid 15: exited on signal 11 Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
According to Chuck Robey: I know that, back when we ran aout, our gcc was a long way changed from the stock gnu gcc ... I'm wondering how much our gcc is changed, now, from the gcc that is the regular GNU distribution? gcc was not that different, it was mostly the binutils chain (as, ld and all that stuff) because a.out was not supported anymore by modern versions. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #70: Sat Feb 27 09:43:08 CET 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: lockmgr panic with mmap()
The attached program sometimes causes a lockmgr panic. I do not think is always
did. I am running 4.0-CURRENT form Feb 19.
The trace is:
panic lockmgr: locking against self
lockmgr
mv_map_growstack
grow_stack
trap_pfault
trap
calltrap
subyte
syscall
...
A command on a running image such as this usually does it, though I do not
know what
conditions are neccessary:
fincore /usr/local/netscape-4.5/communicator-4.5.bin
Here is a simpler example.
---
#include sys/param.h
#include sys/mman.h
#include err.h
#include stdlib.h
#define SIZE(32 * 1024 * 1024)
int
main(void)
{
void *p;
char vec[SIZE / PAGE_SIZE];
p = malloc(SIZE);
if (mincore(p, SIZE, vec) != 0)
err(1, mincore);
return (0);
}
---
mincore() locks the vmspace map, and initialises vec[] a byte at a time
using subyte(). When vec[] is sufficiently large, it is not all in core
initially and a page fault occurs in subyte(). The new stack growing
code locks the vmspace map early and panics.
Bruce
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: gcc
On Sun, Feb 28, 1999 at 09:32:51AM +, Doug Rabson wrote: On Sat, 27 Feb 1999, Jordan K. Hubbard wrote: I for one would love to see 2.8.1 or newer in the tree for my own, selfish reasons. Many ports (new architectures) would benefit from this. Is that to say that you prefer it over egcs 1.1.1? If so, why? I have found egcs to be slightly better at C++ code (for my own projects anyway). I believe that it may produce better code too but I don't have any real evidence. egcs is much closer to ISO-14882 (ISO C++), that was finished AFTER gcc2.8.1 was released. So if one wants to do standard conform C++ programing, egcs is the choice at the time being. (though it also doens't implement all features of the standard yet). -- German Tischlerta...@gaspode.franken.de Apple eaten (core dumped) ta...@cip.informatik.uni-wuerzburg.de To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
%On Sat, 27 Feb 1999, Jordan K. Hubbard wrote: % % I for one would love to see 2.8.1 or newer in the tree for my own, % selfish reasons. Many ports (new architectures) would benefit from % this. % % Is that to say that you prefer it over egcs 1.1.1? If so, why? % %I have found egcs to be slightly better at C++ code (for my own projects %anyway). I believe that it may produce better code too but I don't have %any real evidence. The ACE people recommend egcs. Taken directly from ~ace/ACE-INSTALL.html: ACE/TAO don't seem to build well with g++ 2.8.1. We routinely use g++ 2.7.2.3, egcs 1.0.2, and egcs 1.0.3, and recommend those versions. egcs 1.1.1 is reported to be OK, as well. TAO is quite an exercise for a C++ compiler, and I build it just fine on -current with the egcs in ports. Russell To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: tail /proc/map/*
Bruce Evans wrote:
tail(1) assumes that mmap(2) works on works on regular files. mmap(2) on
the irregular regular files /proc/*/map returns success but doesn't work.
IMO, it ought to work. There should be no reason why regular files on
procfs are more irregular than regular files on NFS.
The first access to the mmapped memory usually causes the kernel to
printf messages like the following:
vnode_pager: *** WARNING *** stale FS getpages
(Still no such messages here. I still don't run the Terry's submission
that just introduced the message and spread a lot of same trivial
getpages/putpages routines over the kernel... I hope to clean out all
this junk some day, (when everyone will finally forget that matter ;-)
The message is not quite relevant to the problem, though.)
No strategy for buffer at 0xf12828e8
: 0xf3877800: type VREG, usecount 4, writecount 0, refcount 0, flags (VOBJBUF)
tag VT_PROCFS, type 11, pid 591, mode 124, flags 0
: 0xf3877800: type VREG, usecount 4, writecount 0, refcount 0, flags (VOBJBUF)
tag VT_PROCFS, type 11, pid 591, mode 124, flags 0
vnode_pager_getpages: I/O read error
That is because procfs define a bogus BMAP operation, but don't define
a STRATEGY operation. The BMAP operation apparently only useful to
break mmap(2).
After the BMAP code removed, another procfs bugs become apparent.
procfs claim that /proc/*/map files are all sizeof(struct regs)( == 76) bytes
length (:-|), but don't allow read only 76 bytes from the 'map' file.
It confuse the vm code that conver mmap to read, but it also may
confuse other things. If I change the size of the 'map' file to something
larger, tail /proc/*/map output something quite reasonable.
I think procfs_domap should do what requested, and should not try to
guarantee atomicity, as now: anyhow, any file may change it content
between reads, not just under procfs. Also, procfs could compute 'map'
file size more accurately.
Apparently, such a mmap implementation has coherency problems. But I
don't think that they are more difficult to solve (or more serious)
than in NFS case.
Dima
P.S. This is the changes that allow me to see a reasonable good result
from 'tail /proc/*/map'.
--- procfs_vnops.c Sun Feb 28 15:33:52 1999
+++ procfs_vnops.c Sun Feb 28 17:29:22 1999
@@ -560,6 +560,12 @@
case Ptype:
case Pmap:
+ vap-va_bytes = vap-va_size = 4096;
+ vap-va_nlink = 1;
+ vap-va_uid = procp-p_ucred-cr_uid;
+ vap-va_gid = procp-p_ucred-cr_gid;
+ break;
+
case Pregs:
vap-va_bytes = vap-va_size = sizeof(struct reg);
vap-va_nlink = 1;
@@ -982,7 +988,7 @@
{ vop_abortop_desc,(vop_t *) procfs_abortop },
{ vop_access_desc, (vop_t *) procfs_access },
{ vop_advlock_desc,(vop_t *) procfs_badop },
- { vop_bmap_desc, (vop_t *) procfs_bmap },
+ /*{ vop_bmap_desc, (vop_t *) procfs_bmap },*/
{ vop_close_desc, (vop_t *) procfs_close },
{ vop_create_desc, (vop_t *) procfs_badop },
{ vop_getattr_desc,(vop_t *) procfs_getattr },
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Some (a.out) world breakage...
Make world (with no -DNOAOUT or whatever that switch is), ends up like this: -- Building legacy libraries -- (echo '#define LENGTH 20'; sed -e 's/mdX/sha/g' -e 's/MDX/SHA_/g' -e 's/SHA__/SHA_/g' /usr/src/lib/libmd/mdXhl.c) sha0hl.c cc -O -pipe -I/usr/src/lib/libmd -DSHA1_ASM -DELF -DRMD160_ASM -DELF -I/usr/obj/aout/usr/src/tmp/usr/include -c sha0hl.c -o sha0hl.o cc -O -pipe -I/usr/src/lib/libmd -DSHA1_ASM -DELF -DRMD160_ASM -DELF -I/usr/obj/aout/usr/src/tmp/usr/include -c /usr/src/lib/libmd/sha1c.c -o sha1c.o (echo '#define LENGTH 20'; sed -e 's/mdX/sha/g' -e 's/MDX/SHA1_/g' -e 's/SHA1__/SHA1_/g' /usr/src/lib/libmd/mdXhl.c) sha1hl.c cc -O -pipe -I/usr/src/lib/libmd -DSHA1_ASM -DELF -DRMD160_ASM -DELF -I/usr/obj/aout/usr/src/tmp/usr/include -c sha1hl.c -o sha1hl.o cc -I/usr/src/lib/libmd -DSHA1_ASM -DELF -DRMD160_ASM -DELF -I/usr/obj/aout/usr/src/tmp/usr/include -c /usr/src/lib/libmd/i386/sha.S -o sha.o sha1-586.s: Assembler messages: sha1-586.s:56: Error: Alignment too large: 15. assumed. *** Error code 1 Stop. Quite obviously defining ELF for the entire legacy library build, but waiting to really break in 'libmd'. I did look in the broken file, and noted that ALIGN was defined as 16 in the 'ELF' case, and 4 in the 'OUT' case. It looks impossible (to me) for 'OUT' to be defined while compiling that file (/usr/src/lib/libmd/i386/sha.S). I guess it's time to quit building a.out? :-) -- Zach Heilig z...@uffdaonline.net Americans are sensitive about their money, and since this was the first major change in the greenback in nearly 70 years, a radical redesign might have been too much for consumers to comprehend -- John Iddings [COINage, Feb. 1999]. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
still having buildworld trouble for libmd
cc -I/usr/src/lib/libmd -DSHA1_ASM -DELF -DRMD160_ASM -DELF -I/usr/obj/aout/usr/src/tmp/usr/include -c /usr/src/lib/libmd/i386/sha.S -o sha.o sha1-586.s: Assembler messages: sha1-586.s:56: Error: Alignment too large: 15. assumed. *** Error code 1 I have an elf i386. The build seems broken. What's up? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
In message 20655.920182...@zippy.cdrom.com Jordan K. Hubbard writes: : I for one would love to see 2.8.1 or newer in the tree for my own, : selfish reasons. Many ports (new architectures) would benefit from : this. : : Is that to say that you prefer it over egcs 1.1.1? If so, why? No. I'd love to see 2.8.1 or newer. egcs 1.1.1 is newer. I'd prefer egcs, for a variety of reasons... Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: still having buildworld trouble for libmd
On Sun, Feb 28, 1999 at 08:39:46AM -0800, Matthew Jacob wrote: cc -I/usr/src/lib/libmd -DSHA1_ASM -DELF -DRMD160_ASM -DELF -I/usr/obj/aout/usr/src/tmp/usr/include -c /usr/src/lib/libmd/i386/sha.S -o sha.o sha1-586.s: Assembler messages: sha1-586.s:56: Error: Alignment too large: 15. assumed. *** Error code 1 I have an elf i386. The build seems broken. What's up? The '-DELF' bit on the command line (it's building a.out libraries). It looks to be a problem with building all legacy libraries (-DELF is there for the entire a.out library build). libmd specifically does not have any way of building a.out (the makefile will not add '-DOUT' to the command line). -- Zach Heilig z...@uffdaonline.net Americans are sensitive about their money, and since this was the first major change in the greenback in nearly 70 years, a radical redesign might have been too much for consumers to comprehend -- John Iddings [COINage, Feb. 1999]. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: still having buildworld trouble for libmd
On Sun, 28 Feb 1999, Matthew Jacob wrote:
cc -I/usr/src/lib/libmd -DSHA1_ASM -DELF -DRMD160_ASM -DELF
-I/usr/obj/aout/usr/src/tmp/usr/include -c /usr/src/lib/libmd/i386/sha.S
-o sha.o
sha1-586.s: Assembler messages:
sha1-586.s:56: Error: Alignment too large: 15. assumed.
*** Error code 1
I have an elf i386. The build seems broken. What's up?
I guessed from commit logs that maybe Garrett had something to do with
it, and talking with him last night, I disabled the build of two
assembler files via the libmd Makefile:
.if (${OBJFORMAT} == elf) -- NEW
.if exists(${MACHINE_ARCH}/sha.S)
SRCS+= sha.S
CFLAGS+= -DSHA1_ASM -DELF
.endif
.if exists(${MACHINE_ARCH}/rmd160.S)
SRCS+= rmd160.S
CFLAGS+= -DRMD160_ASM -DELF
.endif
.endif-- NEW
When this fixed things, I asked Garrett about it, because I know nothing
at all about libmd or what uses libmd, but he didn't get back to me.
That does fix all the rest of the buildworld.
Does anyone know if this fix, only active really in the legacy build,
would have negative effects? I want to do the installworld, but I'm
nervous about this (I don't like doing things by accident!)
+---
Chuck Robey | Interests include any kind of voice or data
chu...@glue.umd.edu | 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: gcc
Warner Losh wrote: In message 20655.920182...@zippy.cdrom.com Jordan K. Hubbard writes: : I for one would love to see 2.8.1 or newer in the tree for my own, : selfish reasons. Many ports (new architectures) would benefit from : this. : : Is that to say that you prefer it over egcs 1.1.1? If so, why? No. I'd love to see 2.8.1 or newer. egcs 1.1.1 is newer. I'd prefer egcs, for a variety of reasons... Warner A fair bit of work as been done on getting our stuff and egcs 1.1.1 merged and into shape. I see egcs 1.1.2 appears to be on the horizon, that won't be much problem when it arrives as I expect it's pretty close to the 1.1.1 layout. The main holdups have been getting the native egcs build to do something more sensible with regards to -aout/-elf, and, if things work out, a bit better cross-compile support. (Note, the cross compile stuff doesn't work too happily with the existing bmake glue and hacks in the code.) I think I've got the threaded vs setjump/longjump exception stuff sorted out and runtime switchable based on -thread etc. I suspect libg++ is approaching delete material. libstdc++ comes with egcs, and a hacked up libg++ is floating around that we can probably use, but I wonder if it's time to loose it and keep just libstdc++. libg++ on it's own isn't all that useful, and would probably be better as a port for the few (if any) things that actually uses it's (non-standard) class libraries. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: still having buildworld trouble for libmd
Hmm! Yes, I guess we'll wait on Garrett, but I too need to do an installworld so gratefully have borrowed your change! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Some (a.out) world breakage...
In article 19990228103315.a37...@znh.org, Zach Heilig z...@uffdaonline.net wrote: Make world (with no -DNOAOUT or whatever that switch is), ends up like this: -- Building legacy libraries -- (echo '#define LENGTH 20'; sed -e 's/mdX/sha/g' -e 's/MDX/SHA_/g' -e 's/SHA__/SHA_/g' /usr/src/lib/libmd/mdXhl.c) sha0hl.c cc -O -pipe -I/usr/src/lib/libmd -DSHA1_ASM -DELF -DRMD160_ASM -DELF -I/usr/obj/aout/usr/src/tmp/usr/include -c sha0hl.c -o sha0hl.o cc -O -pipe -I/usr/src/lib/libmd -DSHA1_ASM -DELF -DRMD160_ASM -DELF -I/usr/obj/aout/usr/src/tmp/usr/include -c /usr/src/lib/libmd/sha1c.c -o sha1c.o (echo '#define LENGTH 20'; sed -e 's/mdX/sha/g' -e 's/MDX/SHA1_/g' -e 's/SHA1__/SHA1_/g' /usr/src/lib/libmd/mdXhl.c) sha1hl.c cc -O -pipe -I/usr/src/lib/libmd -DSHA1_ASM -DELF -DRMD160_ASM -DELF -I/usr/obj/aout/usr/src/tmp/usr/include -c sha1hl.c -o sha1hl.o cc -I/usr/src/lib/libmd -DSHA1_ASM -DELF -DRMD160_ASM -DELF -I/usr/obj/aout/usr/src/tmp/usr/include -c /usr/src/lib/libmd/i386/sha.S -o sha.o sha1-586.s: Assembler messages: sha1-586.s:56: Error: Alignment too large: 15. assumed. *** Error code 1 Stop. Quite obviously defining ELF for the entire legacy library build, but waiting to really break in 'libmd'. I did look in the broken file, and noted that ALIGN was defined as 16 in the 'ELF' case, and 4 in the 'OUT' case. It looks impossible (to me) for 'OUT' to be defined while compiling that file (/usr/src/lib/libmd/i386/sha.S). I guess it's time to quit building a.out? :-) This problem can be solved easily. Instead of .align the code should use .p2align 4, which behaves the same for a.out as it does for ELF. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Nobody ever went broke underestimating the taste of the American public. -- H. L. Mencken To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Some (a.out) world breakage...
On Sun, 28 Feb 1999, John Polstra wrote: I did look in the broken file, and noted that ALIGN was defined as 16 in the 'ELF' case, and 4 in the 'OUT' case. It looks impossible (to me) for 'OUT' to be defined while compiling that file (/usr/src/lib/libmd/i386/sha.S). I guess it's time to quit building a.out? :-) This problem can be solved easily. Instead of .align the code should use .p2align 4, which behaves the same for a.out as it does for ELF. In test, this didn't work, so I misunderstood something. I'm going to show a segment of file /usr/src/lib/libmd/i386/sha.S: gcc2_compiled.: .text .align ALIGN .globl sha1_block_x86 TYPE(sha1_block_x86,@function) sha1_block_x86: I tried changing the .align to .p2align, and got this error: cc -I/usr/src/lib/libmd -DSHA1_ASM -DELF -DRMD160_ASM -DELF -c /usr/src/lib/libmd/i386/sha.S -o sha.o /usr/tmp/ccx85357.s: Assembler messages: /usr/tmp/ccx85357.s:57: Error: Alignment too large: 15 assumed *** Error code 1 I tried changing .align instead to .p2align (in case I didn't read you literally enough) and it complained of extra arguments. BTW, in the code, ALIGN is defined earlier to be 4. Last notes: It used to break before this, only in the aout setting. Now it breaks for elf and aout. Also, the other file in ./i386, rmd160.S, has an identical problem. All this is done with the libmd Makefile as original (the fix I worked out with Garrett, to take the assembler files completely out of the aout build, I removed for this test). +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | 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: Some (a.out) world breakage...
On Sun, Feb 28, 1999 at 01:18:50PM -0500, Chuck Robey wrote: cc -I/usr/src/lib/libmd -DSHA1_ASM -DELF -DRMD160_ASM -DELF -c /usr/src/lib/libmd/i386/sha.S -o sha.o /usr/tmp/ccx85357.s: Assembler messages: /usr/tmp/ccx85357.s:57: Error: Alignment too large: 15 assumed *** Error code 1 ... BTW, in the code, ALIGN is defined earlier to be 4. No, because of the '-DELF', ALIGN is defined to be 16. -- Zach Heilig z...@uffdaonline.net Americans are sensitive about their money, and since this was the first major change in the greenback in nearly 70 years, a radical redesign might have been too much for consumers to comprehend -- John Iddings [COINage, Feb. 1999]. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Some (a.out) world breakage...
Chuck Robey wrote: This problem can be solved easily. Instead of .align the code should use .p2align 4, which behaves the same for a.out as it does for ELF. In test, this didn't work, so I misunderstood something. Yes, you did. :-) Get rid of ALIGN entirely. Change all instances of .align ALIGN to .p2align 4. John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Nobody ever went broke underestimating the taste of the American public. -- H. L. Mencken To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
In message 199902281707.baa63...@spinner.netplex.com.au Peter Wemm writes: : better cross-compile support. (Note, the cross compile stuff doesn't work : too happily with the existing bmake glue and hacks in the code.) Yes. That's one of the big reasons that I'd like to see a more modern compiler. I'd love to have the ability to cross compile the entire world, and right now the main hold up is gcc. I'll be happy to work with whoever to make sure that this functionality works. Would that be you Peter? Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: lockmgr panic with mmap()
Please forgive me if this is a silly question.
Since bugs do happen, deadlock can occur in the kernel.
Is it not possible in such cases to simply detect the deadlock, and kill
one of the user processes involved in the deadlock, thus releasing one
of the resources involved in the deadlock? Then you would log
diagnostic information and let the system continue normally. If a user
deliberately does something to deadlock the kernel, his process just
gets killed and a denial-of-service attack has been averted.
As I vaguely recall, VAX/VMS used to do soemthing like this if a
deadlock was detected.
Rahul
Date: Sun, 28 Feb 99 23:52:57 +1100
From: Bruce Evans b...@zeta.org.au
To:curr...@freebsd.org, pango...@home.com
Message-Id: 199902281252.xaa24...@godzilla.zeta.org.au
Subject: Re: lockmgr panic with mmap()
The attached program sometimes causes a lockmgr panic. I do not think is
always
did. I am running 4.0-CURRENT form Feb 19.
The trace is:
panic lockmgr: locking against self
lockmgr
mv_map_growstack
grow_stack
trap_pfault
trap
calltrap
subyte
syscall
...
A command on a running image such as this usually does it, though I do not
know what
conditions are neccessary:
fincore /usr/local/netscape-4.5/communicator-4.5.bin
Here is a simpler example.
---
#include sys/param.h
#include sys/mman.h
#include err.h
#include stdlib.h
#define SIZE(32 * 1024 * 1024)
int
main(void)
{
void *p;
char vec[SIZE / PAGE_SIZE];
p = malloc(SIZE);
if (mincore(p, SIZE, vec) != 0)
err(1, mincore);
return (0);
}
---
mincore() locks the vmspace map, and initialises vec[] a byte at a time
using subyte(). When vec[] is sufficiently large, it is not all in core
initially and a page fault occurs in subyte(). The new stack growing
code locks the vmspace map early and panics.
Bruce
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: gcc
[fwd to -current] Hi Chuck, I must agree with your concerns about the bleeding-edge nature of EGCS. At Glenayre we've tried several times to move up to EGCS for our embedded development efforts, only to beat a hasty retreat back to GCC because of code generation and execution bugs in the compiler. Things are improving but I'd be extremely wary of a wholesale shift to EGCS just now. As an interesting side note, Joel Sherrill of the RTEMS project is a director of the EGCS project; Even RTEMS patches the EGCS distribution (!) Since RTEMS is using networking code from FreeBSD, perhaps he might be a good contact for those maintaining the FreeBSD compiler? Cheers, Jerry Hicks wghi...@bellsouth.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: lockmgr panic with mmap()
:Please forgive me if this is a silly question. : :Since bugs do happen, deadlock can occur in the kernel. : :Is it not possible in such cases to simply detect the deadlock, and kill :one of the user processes involved in the deadlock, thus releasing one :of the resources involved in the deadlock? Then you would log :diagnostic information and let the system continue normally. If a user :deliberately does something to deadlock the kernel, his process just :gets killed and a denial-of-service attack has been averted. : :As I vaguely recall, VAX/VMS used to do soemthing like this if a :deadlock was detected. : :Rahul Well, the lockmgr panic with mmap() is something that ought to be easily fixable ( by whoever did the stack changes ). There are also deadlock problems when read()ing or write()ing a file-backed mmap()'d area. Most of the deadlocks remaining in the kernel are more complex and often cannot be detected without significant new work. For example, there is no tracking of the PIDs holding shared locks, only exclusive locks. Deadlocks can occur due to chains of locks across multiple processes ( e.g. 5 or 6 or more ) that loop back in on themselves. Detecting the loop is the hard part. This is known as 'deadlock detection'. It's the same sort of deadlock detection commercial SQL databases use to implement transactions and rollback. In FreeBSD's case, the issue is somewhat more complex due to things that are not strictly locks causing deadlocks - such as a low memory condition causing a process holding an inode lock to block and then the syncer blocking on the same inode. The syncer is thus unable to run and thus unable to sync the dirty buffers clogging memory to disk. Things like that. -Matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
mtree stuff?
While doing yet another buildworld to check my libmd changes, I saw that a couple of odd new components seem to be added to the build, at the start of the buildworld, and also near the start of the legacy tools build. I'm not sure what's happening, but it *looks* like every target in the whole tree is being scanned, *twice*. I know that Jordan's been at mtree, and there have been some other changes ... I don't have more time right now to give, but something unusual is suddenly going on in the buildworlds. +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | 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: gcc
The main holdups have been getting the native egcs build to do something more sensible with regards to -aout/-elf, and, if things work out, a bit Work might go a bit faster if the work that has been done already would be posted somewhere. Having such an important issue being responsible on a single over-worked person is not productive. ***Like Jordan said, we get NO new install and package utils until EGCS is in the tree.*** Possibly people don't realize how much the public is interested in improved install and package tools. At a recent FreeBSD users's group meeting in San Francisco, Jordan spoke of the new progress on the new tools. I'd guess between his speal and the tons of interest and questions that came up, that the topic was discussed well over an hour. At a minium the stuff that has already been done should be added to the port. ALSO, don't forget that just getting a FreeBSD'ized EGCS is just the first step. We will have to test ``build world'' many times and I'm sure we will have to change base code to compile as we like with EGCS. The more people that are allowed to get involved with this the faster things will go. In addition, at schools it is getting harder and harder to convince people to try FreeBSD when we have a broken C++ compiler in the base system. In case some aren't aware, C++ is now part of the standard CS curriculum these days. I suspect libg++ is approaching delete material. libstdc++ comes with egcs, and a hacked up libg++ is floating around that we can probably use, but I wonder if it's time to loose it and keep just libstdc++. It is time to dump libg++. Once EGCS is in the tree, I'll make a port of the libg++ meant for post g++ 2.8 compilers. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
In message 19990228131503.a1...@relay.nuxi.com David O'Brien writes: : ALSO, don't forget that just getting a FreeBSD'ized EGCS is just the : first step. We will have to test ``build world'' many times and I'm sure : we will have to change base code to compile as we like with EGCS. The : more people that are allowed to get involved with this the faster things : will go. I really want to be involved in this. I'm quite keen on having a newer, cross-compile friendlier compiler in the tree. Point me at something, and I'll test it. BTW, do we need to update binutils? Or are they new enough? I know that my needs for binutils are covered by the missing bits in the current version we have in the tree. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: lockmgr panic with mmap()
On Sun, Feb 28, 1999 at 11:52:57PM +1100, Bruce Evans wrote:
[snip]
Here is a simpler example.
---
#include sys/param.h
#include sys/mman.h
#include err.h
#include stdlib.h
#define SIZE(32 * 1024 * 1024)
int
main(void)
{
void *p;
char vec[SIZE / PAGE_SIZE];
p = malloc(SIZE);
if (mincore(p, SIZE, vec) != 0)
err(1, mincore);
return (0);
}
---
mincore() locks the vmspace map, and initialises vec[] a byte at a time
using subyte(). When vec[] is sufficiently large, it is not all in core
initially and a page fault occurs in subyte(). The new stack growing
code locks the vmspace map early and panics.
It appears to me the potential for deadlock exists in the old grow code
too, but is less likely.
I've attached a patch that addresses the issue, though there is a
question if this is the best solution.
With the old grow code, if the map lock is already held, one of the
following will be true
a) the grow code doesn't get executed because the va is not
in the stack region, which is equivalent to grow returning
success
b) the grow code returns success because there's no need to
grow the region because the va is aready in the mapped region.
c) the grow code returns false if the va is within the stack
region and there's no room left, which normally will result
in a SIGSEGV
d) the grow code attempts to grow the stack via vm_map_find and
will then deadlock at the vm_map_lock call
With this patch, if the map lock is already held, by always returning
success, cases a) and b) will be the same as before. For case c)
the code will attempt to continue to execute, generally calling
vm_fault, which should, I think, generate a SIGSEGV, essentially
the same result as the old code, but via a different path. Case d)
will now continue executing in a manner equivalent to the new case c).
The question is whether there is a way to do the autogrow function if
the map lock is already held.
--
Richard Seaman, Jr. email: d...@tar.com
5182 N. Maple Lanephone: 414-367-5450
Chenequa WI 53058 fax: 414-367-5850Index: vm_map.c
===
RCS file: /home/ncvs/src/sys/vm/vm_map.c,v
retrieving revision 1.152
diff -c -r1.152 vm_map.c
*** vm_map.c1999/02/24 21:26:25 1.152
--- vm_map.c1999/02/28 20:41:25
***
*** 663,668
--- 663,674
int rv;
int is_procstack = 0;
+
+ #define vm_map_locked(map) lockstatus((map)-lock)
+
+ if (vm_map_locked(map))
+ return (KERN_SUCCESS);
+
vm_map_lock(map);
/* If addr is already in the entry range, no need to grow.*/
Re: gcc
In article 199902282119.oaa81...@harmony.village.org, Warner Losh i...@harmony.village.org wrote: BTW, do we need to update binutils? Or are they new enough? I know that my needs for binutils are covered by the missing bits in the current version we have in the tree. I'm pretty sure our existing binutils are fine. They're the newest GNU version, and they work OK with the egcs and gcc-2.8.1 ports. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Nobody ever went broke underestimating the taste of the American public. -- H. L. Mencken To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
On Sun, 28 Feb 1999, David O'Brien wrote:
In addition, at schools it is getting harder and harder to convince people
to try FreeBSD when we have a broken C++ compiler in the base system. In
case some aren't aware, C++ is now part of the standard CS curriculum
these days.
I work as System Administrator at a Canadian University that is *totally*
wired. All new students get a laptop as part of their tuition, and profs
make heavy use of it. The Computer Science department's template is a
Win95/Linux mix...and the reason has nothing to do with C++.
Most of the reason revolves around hardware support...the laptops are all
IBM thinkpads, and the Linux kernel is barely able to drive the ethernet
card used, as well as graphics...FreeBSD didn't even stand a chance :(
It should be too easy to replace the compiler after the system is
installed...and shouldn't be seen as a major hindrance...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scra...@hub.org secondary: scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: gcc
It should be too easy to replace the compiler after the system is installed...and shouldn't be seen as a major hindrance... But as Micro$hit knows, being able to check off feature boxes is important. Here, the CS dept encourages people that own a PC to install a Unix at home (we are still 100% Unix based for classes). When I push FreeBSD, I get asked if EGCS comes with it. I say no not by default, but we have a very easy to add version of it. They say, why go through the trouble if Linux already has it by default. Same for our support people. They are the laziest and most non-computer enthusiast group I've ever seen. Path of least effort is what wins with them. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
On Sun, 28 Feb 1999, David O'Brien wrote: It should be too easy to replace the compiler after the system is installed...and shouldn't be seen as a major hindrance... But as Micro$hit knows, being able to check off feature boxes is important. Here, the CS dept encourages people that own a PC to install a Unix at home (we are still 100% Unix based for classes). When I push FreeBSD, I get asked if EGCS comes with it. I say no not by default, but we have a very easy to add version of it. They say, why go through the trouble if Linux already has it by default. Same for our support people. They are the laziest and most non-computer enthusiast group I've ever seen. Path of least effort is what wins with them. Please keep in mind that if, in our haste, we import a compiler that puts instability into FreeBSD, then we've drunk poison. The feature list won't matter, the fact that we're up to date won't matter, the fact that FreeBSD suddenly, out of the blue, became unstable is the only thing that anyone will remember. I'm not against egcs if it can be shown to be stable. I'm completely against it if it exposes FreeBSD to bugs outside our control. That's my only argument in favor of gcc28, but *please* don't disregard it. I am in CS classes too, and David's points are precisely correct, but they *aren't* the number one concern, even for a student who would *love* to have the latest compiler. Maintaining FreeBSD's exemplary reputation is my number one concern here. If it means asking certain folks (like me!) to install a port to get a particular compiler, that's then something we should view separately (not less, but separately). If David comes up with a test compiler, I want to install it, and test it myself for at least 20 buildworld/installworldkernel/cvsup cycles. I would want at least several others to report their results too. We need to move forward *quickly* to either gcc28 or egcs, but please, don't be willing to sacrifice stability. I can do that testing with automated scripts, so it wouldn't need lots of my time, and I would do that happily. +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | 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: panic: zone: entry not free
Eivind Eklund eiv...@freebsd.org writes: That is, INVARIANTS in kernel incompatible with dynamic loading. Somehow this strikes me as a Bad Thing... It _is_ a bad thing. I've been pondering what to do with the intrusive invariant checks - make them dependent on INTRUSIVE_INVARIANTS, perhaps? That would still make some KLDs incompatible with INTRUSIVE_INVARIANTS, but that is probably the best we can do. I think that the goal should be to make KLDs work with all kinds of kernels. And the only place where this seems to be a problem is with zalloc and zfree. So it seems to me that one of the following could be done to solve it: a. make zalloc and zfree non-inline b. call zalloci and zfreei in code that can end up in KLDs c. call zalloci and zfreei everywhere where it's not performance-critical /assar To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
The main holdups have been getting the native egcs build to do something more sensible with regards to -aout/-elf, and, if things work out, a bit better cross-compile support. (Note, the cross compile stuff doesn't work too happily with the existing bmake glue and hacks in the code.) I think I've got the threaded vs setjump/longjump exception stuff sorted out and runtime switchable based on -thread etc. I'd personally be happy with an egcs that just did sensible things with ELF, though I guess a.out is a bonus(?) of sorts. Still, I just tweaked the egcs 1.1.1 configure script to replace my system compiler entirely and then built the world and kernel from it - the resulting system appears to work, provided that you comment out the compiler from the build so that it doesn't clobber itself. I think we really are probably holding this up a bit too much on the small points rather than the big ones. :) I suspect libg++ is approaching delete material. libstdc++ comes with egcs, and a hacked up libg++ is floating around that we can probably use, but I wonder if it's time to loose it and keep just libstdc++. libg++ on I agree. I've done that here as well. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
Work might go a bit faster if the work that has been done already would be posted somewhere. Having such an important issue being responsible on a single over-worked person is not productive. ***Like Jordan said, we get NO new install and package utils until EGCS is in the tree.*** Would you like to sort of be egcs czar for awhile and coordinate this with the other volunteers? No slight to Peter intended, who's sort of been doing that up to now, but he's just too damn busy to be principal contact for this I think. Unless we bust soemthing loose here, we're going to be discussing egcs and a possible upgrade to it at this time next year. At a minium the stuff that has already been done should be added to the port. Can you chase Peter around until he provides at least that much? :) It is time to dump libg++. Once EGCS is in the tree, I'll make a port of the libg++ meant for post g++ 2.8 compilers. What's the exact division between libg++ and libstdc++? I'm sure I'm not the only person confused by this one. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
Please keep in mind that if, in our haste, we import a compiler that puts instability into FreeBSD, then we've drunk poison. The feature A legit concern, but also realize that all of us are talking about 4.0 here - the new compiler would be an issue we'd have up to a full year on before the product it's in goes mainstream. If that's not enough time to work out the compiler issues after switching, I can't imagine when we WILL have a better time to try and do this then. Progress entails some pain, and if we're unwilling to suffer any at all then progress ceases entirely. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
A legit concern, but also realize that all of us are talking about 4.0 here - the new compiler would be an issue we'd have up to a full year on before the product it's in goes mainstream. If that's not enough time to work out the compiler issues after switching, I can't imagine when we WILL have a better time to try and do this then. Progress entails some pain, and if we're unwilling to suffer any at all then progress ceases entirely. This is interesting, what makes egcs better than gcc? just a dumb question. I agree with Jordan though: no pain no gain. :-) Kenneth Culver To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
On Sun, 28 Feb 1999, Jordan K. Hubbard wrote: Please keep in mind that if, in our haste, we import a compiler that puts instability into FreeBSD, then we've drunk poison. The feature A legit concern, but also realize that all of us are talking about 4.0 here - the new compiler would be an issue we'd have up to a full year on before the product it's in goes mainstream. If that's not enough time to work out the compiler issues after switching, I can't imagine when we WILL have a better time to try and do this then. Progress entails some pain, and if we're unwilling to suffer any at all then progress ceases entirely. I keep on hearing about how we're losing because we don't have the 3 month old latest feature, and I want to show that we're equally concerned with stability, that's all. I want forward movement too, but every time I see something one-sided, like the comments about the CS courses (and that being in itself enough reason to move forward), I have to bring this up. I want us to go to egcs just as much as you do, but I don't want us to give an obvious show of abandoning our previous professional approach to things. Every time I see a post that is one-sidedly aimed towards the latest untested thing, with not one word about making certain it *works*, I want to tell folks that going that way, there be dragons. Yes, let's try egcs. I want to do buildworlds/installworlds/new kernel builds here with it for a while. Do you have the Makefiles you used to cut it out of your build? Could I install egcs out of ports, and do that testing? I want to do that, if it would contribute. Lots of it. I want to show that it's TESTED. TESTED. TESTED. +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | 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: gcc
On Sun, Feb 28, 1999 at 05:59:08PM -0500, Kenneth Wayne Culver wrote: This is interesting, what makes egcs better than gcc? just a dumb question. I agree with Jordan though: no pain no gain. :-) IMHO, maintence. EGCS is actively being developed. Gcc 2.8.x might be, but it is hard to see. Also Jeff Law of the EGCS steering committee, has said that FSF is heavily leaning on GNU GCC 2.9 (or 2.8.2) being some branch along the EGCS tree. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
Chuck Robey chu...@mat.net wrote: Please keep in mind that if, in our haste, we import a compiler that puts instability into FreeBSD, then we've drunk poison. I agree that -STABLE _must_ remain stable. That said, I believe that we _do_ need to move forward. I'd like to see either EGCS or gcc-2.8.1 (and the former seems to be better supported at present) brought into -current as soon as practical. Jordan K. Hubbard j...@zippy.cdrom.com wrote: A legit concern, but also realize that all of us are talking about 4.0 here - the new compiler would be an issue we'd have up to a full year on before the product it's in goes mainstream. I'd like to see it merged back into the 3.x tree earlier than this. The general complaining about compiler related issues (C++ and FORTRAN-77 being the two most recent issues) will continue until the compiler makes it into a release. I think we should be able to easily validate the compiler in time for the 3.x.y release due around October (assuming the 4-monthly releases continue) - maybe even the June release. Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
On Sun, 28 Feb 1999, Chuck Robey wrote:
On Sun, 28 Feb 1999, David O'Brien wrote:
It should be too easy to replace the compiler after the system is
installed...and shouldn't be seen as a major hindrance...
But as Micro$hit knows, being able to check off feature boxes is
important. Here, the CS dept encourages people that own a PC to install
a Unix at home (we are still 100% Unix based for classes). When I push
FreeBSD, I get asked if EGCS comes with it. I say no not by default, but
we have a very easy to add version of it. They say, why go through the
trouble if Linux already has it by default. Same for our support
people. They are the laziest and most non-computer enthusiast group I've
ever seen. Path of least effort is what wins with them.
Please keep in mind that if, in our haste, we import a compiler that
puts instability into FreeBSD, then we've drunk poison. The feature
list won't matter, the fact that we're up to date won't matter, the fact
that FreeBSD suddenly, out of the blue, became unstable is the only
thing that anyone will remember.
Last I heard, that was what the -current source tree was for...has that
changed recently?
Marc G. Fournier
Systems Administrator @ hub.org
primary: scra...@hub.org secondary: scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: gcc
I keep on hearing about how we're losing because we don't have the 3 month old latest feature With EGCS the issue isn't having the latest 3 mo. feature, but we have a totally BROKEN C++ compiler. The STL with it is broken, and it is so far from the ISO C++ standard, it really can't be called C++ any longer. Every time I see a post that is one-sidedly aimed towards the latest untested thing I'm working on the egcs 1.1.x branch. I wouldn't go near their HEAD branch for FreeBSD use. I distrust that code more than I do Micro$oft's. Yes, let's try egcs. I want to do buildworlds/installworlds/new kernel builds here with it for a while. What I have won't build kernels yet. I could hack our system Makefiles to use different compile options, but I don't like that approach. So I'm working on adding our compiler flags and such. Could I install egcs out of ports, and do that testing? I want to do that, if it would contribute. Last I tried, no. IMHO, we are a ways off, but we need to at least be working on it. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
On Sun, 28 Feb 1999, Jordan K. Hubbard wrote:
Please keep in mind that if, in our haste, we import a compiler that
puts instability into FreeBSD, then we've drunk poison. The feature
A legit concern, but also realize that all of us are talking about
4.0 here - the new compiler would be an issue we'd have up to a full
year on before the product it's in goes mainstream. If that's not enough
time to work out the compiler issues after switching, I can't imagine
when we WILL have a better time to try and do this then. Progress
entails some pain, and if we're unwilling to suffer any at all then
progress ceases entirely.
My 2cents...waiting a year before it goes mainstream is really
going to hurt things. There appear to be more and more projects coming
out that are relying on features existent in the C++ in egcs that gcc
can't support. MICO (corba) is one of them...KDE appears to be more
towards it with some of its applications...
Bringing it into 4.0-CURRENT is great, and debugging it there, but
getting it rolled into the 3.x tree should, IMHO, be considered long
before 4.x gets released...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scra...@hub.org secondary: scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: gcc
On Sun, 28 Feb 1999, Kenneth Wayne Culver wrote:
A legit concern, but also realize that all of us are talking about
4.0 here - the new compiler would be an issue we'd have up to a full
year on before the product it's in goes mainstream. If that's not enough
time to work out the compiler issues after switching, I can't imagine
when we WILL have a better time to try and do this then. Progress
entails some pain, and if we're unwilling to suffer any at all then
progress ceases entirely.
This is interesting, what makes egcs better than gcc? just a dumb
question. I agree with Jordan though: no pain no gain. :-)
For those doing, or using, C++ related projects, the current gcc is
BROKEN...egcs, with its faster development cycle (kinda like ours) tends
to be working harder on C++ spec compliance...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scra...@hub.org secondary: scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: gcc
It should be too easy to replace the compiler after the system is installed...and shouldn't be seen as a major hindrance... But as Micro$hit knows, being able to check off feature boxes is important. Here, the CS dept encourages people that own a PC to install a Unix at home (we are still 100% Unix based for classes). When I push FreeBSD, I get asked if EGCS comes with it. I say no not by default, but we have a very easy to add version of it. It does come by default. You have to install it, yes, but then you have to install the compiler with Linux as well. Big hairy deal. They say, why go through the trouble if Linux already has it by default. Same for our support people. They are the laziest and most non-computer enthusiast group I've ever seen. Path of least effort is what wins with them. Order the systems with FreeBSD preinstalled from Gateway. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
On Sun, 28 Feb 1999, The Hermit Hacker wrote: On Sun, 28 Feb 1999, Chuck Robey wrote: On Sun, 28 Feb 1999, David O'Brien wrote: It should be too easy to replace the compiler after the system is installed...and shouldn't be seen as a major hindrance... But as Micro$hit knows, being able to check off feature boxes is important. Here, the CS dept encourages people that own a PC to install a Unix at home (we are still 100% Unix based for classes). When I push FreeBSD, I get asked if EGCS comes with it. I say no not by default, but we have a very easy to add version of it. They say, why go through the trouble if Linux already has it by default. Same for our support people. They are the laziest and most non-computer enthusiast group I've ever seen. Path of least effort is what wins with them. Please keep in mind that if, in our haste, we import a compiler that puts instability into FreeBSD, then we've drunk poison. The feature list won't matter, the fact that we're up to date won't matter, the fact that FreeBSD suddenly, out of the blue, became unstable is the only thing that anyone will remember. Last I heard, that was what the -current source tree was for...has that changed recently? Go looking in the archives, moving our base compiler has come up about 3-4 times a year on hackers since the 386BSD patchkit days. The argument hasn't changed, that stability in our base compiler was worth far more than destabilizing FreeBSD. Current is for experimentation ONLY when it doesn't break the buildworld. Try that, even for a few hours, and you already know what will happen. I'm FOR bringing in egcs, but ONLY if it gets a fair testing, which isn't done in 24 hours, or by one single person. This affects everyone, in as major a way as it's possible to get. This can easily become out of control. Notice how much work and testing went into the aout to elf move? Well, this requires the same thing, as far as testing goes. The very first rule is, the system compiler MUST be stable. If we can prove (and I think we can) that egcs can do that, fine. If we can't prove it (either because it's not true, or because it's just left to chance) then we shouldn't move to egcs. Your argument about CS students needing the better compiler was true, but totally ignored the fact that getting the CS students their compiler IS NOT the top priority, especially since ports can do it (did for me). That's not an argument against it, it's an argument against single-topic myopia. First, consider IF egcs can do the job of being the FreeBSD system compiler (which means building our kernel without any surprises whatsoever), because that's the number 1 requirement. If that's proven, then prove that the userland code and libraries remain similarly stable. After that, then your argument begins to take force, but until that point, it's not germane. +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | 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: gcc
Peter Jeremy wrote: I'd like to see it merged back into the 3.x tree earlier than this. The general complaining about compiler related issues (C++ and FORTRAN-77 being the two most recent issues) will continue until the compiler makes it into a release. I think we should be able to easily validate the compiler in time for the 3.x.y release due around October (assuming the 4-monthly releases continue) - maybe even the June release. We can easily validate the compiler till then assuming when for the import into the -current tree? -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org To make it absolutely clear: you stand on the wrong end of my blasters, so you better get lost before I start target practice! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
How about this, which noone has suggested: Why don't we, for now, import EGCS and libstdc++, getting those working? Of course, here's the trick; let's keep /usr/bin/gcc and /usr/bin/cc as 2.7.2.x like they are now. But for /usr/bin/c++ and /usr/bin/g++, let's have EGCS overwrite the 2.7.2.x ones. As far as I see, EGCS doesn't gain anything for C, and only has gains for C++. Why not switch over partially? We can have 2.7.2.1 not build cc1plus, only cc1 and cc1obj, and have EGCS 1.1.1 build only cc1plus. With this, we get two advantages over the current system. Not only do we get a working, actively supported, C++ compiler, but also we get to keep (for now) the stable, reliable, C compiler we've been depending on for years. Noone can complain that the compiler is destabilizing the system, as all system utilities are in C, not C++, and noone can complain that we're behind the times with C++, since we have the latest C++ compiler and libstdc++. Of course, in the long run, once stability is proven, switching to entirely EGCS would make sense. Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
Assar Westerlund writes:
I think that the goal should be to make KLDs work with all kinds of
kernels.
I've been thinking about this too...
Certainly, for each kernel config option FOO we could have a symbol
in the kernel that a KLD could examine:
static const u_char kernlel_option_FOO = 1;
But what to do about KLD's that want to link against kernel symbols
that may or may not exist? For example, some KLD's that present
interfaces would like to know if BPF is in the kernel, and if so
to support it .. but this means linking with bpfattach(), etc..
Would it be possible to permit 'partial' linking of a KLD, so that
the following code would work no matter what kernel was used?
int
xyz_attach()
{
...
if (kernlel_option_BPF 0)
bpf_attach(..); /* bpf_attach only gets resolved if it exists
* in the kernel; otherwise, it remains NULL but
* that's OK because in that case we don't call it
*/
...
}
Maybe this would require something like this in the KLD..
MODULE_BREAKABLE_LINKS(xyz) { bpfattach, bpf_mtap };
A fair bit of hackery, but probably worth it...
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: gcc
Sounds like an absolute nightmare. Needless to say, I loath this idea. :) How about this, which noone has suggested: Why don't we, for now, import EGCS and libstdc++, getting those working ? Of course, here's the trick; let's keep /usr/bin/gcc and /usr/bin/cc as 2.7.2 .x like they are now. But for /usr/bin/c++ and /usr/bin/g++, let's have EGCS overwrite the 2.7.2.x ones. As far as I see, EGCS doesn't gain anything for C , and only has gains for C++. Why not switch over partially? We can have 2.7.2.1 not build cc1plus, only cc1 and cc1obj, and have EGCS 1.1.1 build onl y cc1plus. With this, we get two advantages over the current system. Not only do we get a working, actively supported, C++ compiler, but also we get to keep (for now) the stable, reliable, C compiler we've been depending on for years. Noone can complain that the compiler is destabilizing the system, as all system utilities are in C, not C++, and noone can complain that we're behin d the times with C++, since we have the latest C++ compiler and libstdc++. Of course, in the long run, once stability is proven, switching to entirely EGCS would make sense. Brian Feldman _ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve!_ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
Brian Feldman gr...@unixhelp.org wrote: [use cc1-2.7.2.1 and ECGS cc1plus] we get to keep (for now) the stable, reliable, C compiler we've been depending on for years. With all the well-known idiosyncrasies that we've been working around for years. Of course, in the long run, once stability is proven, switching to entirely EGCS would make sense. There's a catch-22 here: We can't prove the stability of EGCS until we start using it. Even if we don't make EGCS the base compiler, we need a standard documented mechanism for doing `make world' with EGCS as well as agreement that bug reports using ECGS will be considered. Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
On Sun, 28 Feb 1999, Chuck Robey wrote:
Your argument about CS students needing the better compiler was true,
but totally ignored the fact that getting the CS students their compiler
IS NOT the top priority, especially since ports can do it (did for me).
U, you mis-quoted. I agree with your above, and my statement had to
do with an inability of FreeBSD to run on the hardware that we have (IBM
thinkpad laptops) then anything software related (other then
kernel/driver)...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scra...@hub.org secondary: scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: gcc
On Sun, 28 Feb 1999, Brian Feldman wrote: How about this, which noone has suggested: Why don't we, for now, import EGCS and libstdc++, getting those working? Of course, here's the trick; let's keep /usr/bin/gcc and /usr/bin/cc as 2.7.2.x like they are now. But for /usr/bin/c++ and /usr/bin/g++, let's have EGCS overwrite the 2.7.2.x ones. As far as I see, EGCS doesn't gain anything for C, and only has gains for C++. Why not switch over partially? We can have 2.7.2.1 not build cc1plus, only cc1 and cc1obj, and have EGCS 1.1.1 build only cc1plus. Perhaps on face value it's an interesting idea. Debian does something similar. But egcs post 1.1 (or is it 1.1.1) use binary incompatable exception handling.. as in it's not compatable with gcc 2.8.x. But then you also get to keep two versions of gcc in the CVS tree. Plus egcs also supports more optimizations than our gcc does. Why not rip the compiler out completely and let the user drop in their favorite compiler (egcs, tcc, etc, etc)? ;-) - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
make world broken for a day. some NFS stuff as well.
Sorry if this is the result of work in progress, but i've been unable to make world since saturday night. It happens during the build of libskey. -- cc -fpic -DPIC -pipe -DPERMIT_CONSOLE -D_SKEY_INTERNAL -I/usr/src/lib/libskey -W -Wall -Werror -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/lib/libskey/skey_g etpass.c -o skey_getpass.So cc1: warnings being treated as errors cc1: warnings being treated as errors cc1: warnings being treated as errors /usr/obj/usr/src/tmp/usr/include/stdio.h:354: warning: `__sputc' defined but not used /usr/obj/usr/src/tmp/usr/include/stdio.h:354: warning: `__sputc' defined but not used /usr/obj/usr/src/tmp/usr/include/stdio.h:354: warning: `__sputc' defined but not used *** Error code 1 ** . I'm also noticing that 4.0-current defualt NFS mounts are hanging the client nfsiod gets wedged in sbwait state. I'm able to reproduce it locally by building and installing ssh2 from ports, it hangs during the install phase. The rest of the machine is ok, but i cannot umount -f the NFS mount from the client. I'm going to see if i can do anything to track this down, my goal is that umount -f on NFS should never, EVER not work. It seems that while it's wegded it sends data back and forth (tcpdump) i'm going to look into this, if you have any tests or programs i can run to track it down please tell me. . Lastly i'm interested in writing a man page for kernel.conf i know how to submit diffs, but what about totally new files? just send-pr with it attached? or a url? thanks, -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
On Mon, 1 Mar 1999, Peter Jeremy wrote: Brian Feldman gr...@unixhelp.org wrote: [use cc1-2.7.2.1 and ECGS cc1plus] we get to keep (for now) the stable, reliable, C compiler we've been depending on for years. With all the well-known idiosyncrasies that we've been working around for years. Of course, in the long run, once stability is proven, switching to entirely EGCS would make sense. There's a catch-22 here: We can't prove the stability of EGCS until we start using it. Even if we don't make EGCS the base compiler, we need a standard documented mechanism for doing `make world' with EGCS as well as agreement that bug reports using ECGS will be considered. All gcc/cc do is act as a front-end to cc1/cc1obj/cc1plus. Hence, a second cc for egcs could be used, or maybe using a cc -egcs flag, etc. Peter Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
On Mon, 1 Mar 1999, Peter Jeremy wrote:
There's a catch-22 here: We can't prove the stability of EGCS until we
start using it. Even if we don't make EGCS the base compiler, we need
a standard documented mechanism for doing `make world' with EGCS as well
as agreement that bug reports using ECGS will be considered.
I'd personally love an option for make world to use egcs installed
from the port tree. And perhaps a new mailing list just for throwing
random egcs complaints at. Right now I'm manually building the source
tree with egcs to see how I fair. Any failures I get from building thus
far are replicable with the built in gcc, so egcs doesn't seem to choke on
the code all too much.
The kernel code is a slightly different matter. I get the
following errors:
[20:10]galat...@callisto:/usr/src/sys/compile/CALLISTO# make CC=egcc -k
egcc -c -O3 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -ansi
-nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -DVM_STACK -include
opt_global.h -elf ../../i386/i386/identcpu.c
../../i386/i386/identcpu.c: In function `printcpuinfo':
../../i386/i386/identcpu.c:558: warning: unknown conversion type character
`b' in format
../../i386/i386/identcpu.c:558: warning: too many arguments for format
../../i386/i386/identcpu.c: In function `print_AMD_info':
../../i386/i386/identcpu.c:902: internal error--insn does not satisfy its
constraints:
(insn:HI 278 454 279 (set (reg:SI 2 %ecx)
(subreg:SI (lshiftrt:DI (reg:DI 1 %edx)
(const_int 22)) 0)) 250 {lshrdi3_const_int_subreg} (nil)
(expr_list:REG_DEAD (reg:SI 1 %edx)
(nil)))
toplev.c:1431: Internal compiler error in function fatal_insn
*** Error code 1 (continuing)
egcc -c -O3 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -ansi
-nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -DVM_STACK -include
opt_global.h -elf ../../i386/i386/pmap.c
../../i386/i386/pmap.c: In function `pmap_setdevram':
../../i386/i386/pmap.c:555: internal error--insn does not satisfy its
constraints:
(insn:HI 107 330 109 (set (reg:SI 1 %edx)
(subreg:SI (lshiftrt:DI (reg:DI 0 %eax)
(const_int 12)) 0)) 250 {lshrdi3_const_int_subreg} (nil)
(expr_list:REG_DEAD (reg:SI 0 %eax)
(nil)))
toplev.c:1431: Internal compiler error in function fatal_insn
*** Error code 1 (continuing)
`kernel' not remade because of errors.
[20:10]galat...@callisto:/usr/src/sys/compile/CALLISTO#
Fun fun fun :-)
I built those two files with gcc and rebooted with the output.
Seemed fine.
Tugrul Galatali
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: gcc
Tugrul tug...@ianai.blacksun.org wrote: Right now I'm manually building the source tree with egcs to see how I fair. I tried this with 2.x and gcc-2.8.1, but was never successful - I never managed to stop it building the base compiler and not complain that it hadn't built the base compiler. I didn't spend much effort on it. The kernel code is a slightly different matter. I get the following errors: FWIW, I've had very few problems building 2.x kernels using gcc-2.8.1. (I did find some problems and have previously described fixes or work- arounds for them all). I haven't yet built an ELF gcc or EGCS, so I'm not sure whether there are problems with -current. If the compiler is reporting insn does not satisfy its constraints, then it's probably a compiler bug. Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: SiS 5591
On Sunday, 28 February 1999 at 1:51:45 -0500, Tugrul wrote: Seems to work alright here. dmesg and dd tests follow. [before] mercury# dd if=/dev/zero of=/tmp/zero bs=1024k count=32 32+0 records in 32+0 records out 33554432 bytes transferred in 6.013635 secs (5579725 bytes/sec) mercury# [after] mercury# dd if=/dev/zero of=/tmp/zero bs=1024k count=32 32+0 records in 32+0 records out 33554432 bytes transferred in 5.892770 secs (5634706 bytes/sec) mercury# Not much gain with this drive :/ You shouldn't use files to this kind of test. The buffer cache will falsify the results, especially on relatively small transfers. Try a dd to (or from :-) the raw device. The other thing is, of course, that you can't transfer faster than the disk will allow. If you can do that in PIO mode, you won't get any speed improvement with DMA. What you *will* get is a significant drop in CPU load. Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.1-STABLE #0: Sun Feb 28 01:32:47 EST 1999 galat...@mercury.novastar.com:/usr/src/sys/compile/MERCURY Timecounter i8254 frequency 1193225 Hz CPU: Pentium/P55C (166.45-MHz 586-class CPU) Origin = GenuineIntel Id = 0x543 Stepping=3 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX Could you send me the output of a verbose boot, please? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: mount -o union broken recently?
i just experienced the above today while trying diskless, and while ls only seems to return the entries for the topmost directory, files are accessible if you know the name. no idea if this is of any help. This is exactly the right pointer, thanks! The problem appears to be great -- will try this later today! so... should i bug someone to have this committed back to the tree (or ask permission to do it myself) ? cheers luigi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: gcc
In Reply to Your Message of Sun, 28 Feb 1999 20: 38:49 -0400 Date: Sun, 28 Feb 1999 22:08:14 -0500 From: Jerry Alexandratos alexa...@mail.eecis.udel.edu Message-ID: 199902282208.aa04...@mail.eecis.udel.edu The Hermit Hacker scra...@hub.org says: : On Sun, 28 Feb 1999, Chuck Robey wrote: : : Your argument about CS students needing the better compiler was true, : but totally ignored the fact that getting the CS students their compiler : IS NOT the top priority, especially since ports can do it (did for me). : : U, you mis-quoted. I agree with your above, and my statement had to : do with an inability of FreeBSD to run on the hardware that we have (IBM : thinkpad laptops) then anything software related (other then : kernel/driver)... I think I take offense to this statement. I've been running FreeBSD on various models of StinkPads for the past two+ years. The combo works (mostly) like a charm too. --Jerry 8) Jerry Alexandratos % - % Nothing inhabits my(8 8) alexa...@louie.udel.edu % - %thoughts, and oblivion (8 8) darks...@strauss.udel.edu % - %drives my desires.(8 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
On Sun, 28 Feb 1999, Tugrul wrote: [20:10]galat...@callisto:/usr/src/sys/compile/CALLISTO# make CC=egcc -k [...errors...] [20:10]galat...@callisto:/usr/src/sys/compile/CALLISTO# Never mind, those errors are not faults in EGCS it seems. PGCC introduces those problems. I built my kernel with plain old egcs 1.1.1 and its just fine. When I get home tomorrow I should have a completely EGCS compiled system. So far so good. Tugrul Galatali To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: gcc
On Sun, 28 Feb 1999 alexa...@mail.eecis.udel.edu wrote:
In Reply to Your Message of Sun, 28 Feb 1999 20: 38:49 -0400
Date: Sun, 28 Feb 1999 22:08:14 -0500
From: Jerry Alexandratos alexa...@mail.eecis.udel.edu
Message-ID: 199902282208.aa04...@mail.eecis.udel.edu
The Hermit Hacker scra...@hub.org says:
: On Sun, 28 Feb 1999, Chuck Robey wrote:
:
: Your argument about CS students needing the better compiler was true,
: but totally ignored the fact that getting the CS students their compiler
: IS NOT the top priority, especially since ports can do it (did for me).
:
: U, you mis-quoted. I agree with your above, and my statement had to
: do with an inability of FreeBSD to run on the hardware that we have (IBM
: thinkpad laptops) then anything software related (other then
: kernel/driver)...
I think I take offense to this statement. I've been running FreeBSD on
various models of StinkPads for the past two+ years. The combo works
(mostly) like a charm too.
You are most welcome to take offense to that statement, especially
considering you obviously have no idea what you are taking offesnse at...
Yes, FreeBSD installs on these things, but the network card in them are
not supported by FreeBSD, which defeats the purpose of a Networked
Campus...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scra...@hub.org secondary: scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
RE: gcc
On Sun, 28 Feb 1999, The Hermit Hacker wrote: The Hermit Hacker scra...@hub.org says: : On Sun, 28 Feb 1999, Chuck Robey wrote: : : Your argument about CS students needing the better compiler was true, : but totally ignored the fact that getting the CS students their compiler : IS NOT the top priority, especially since ports can do it (did for me). : : U, you mis-quoted. I agree with your above, and my statement had to : do with an inability of FreeBSD to run on the hardware that we have (IBM : thinkpad laptops) then anything software related (other then : kernel/driver)... I think I take offense to this statement. I've been running FreeBSD on various models of StinkPads for the past two+ years. The combo works (mostly) like a charm too. You are most welcome to take offense to that statement, especially considering you obviously have no idea what you are taking offesnse at... Yes, FreeBSD installs on these things, but the network card in them are not supported by FreeBSD, which defeats the purpose of a Networked Campus... What are the most commonly found chipsets in these thinkpads? -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
It is time to dump libg++. Once EGCS is in the tree, I'll make a port of the libg++ meant for post g++ 2.8 compilers. What's the exact division between libg++ and libstdc++? I'm sure I'm not the only person confused by this one. :) libg++ was a set of standard classes for strings, lists, etc. created by FSF to help others from inventing the wheel. Stroustrup has commented that one of his bigger mistakes was releasing C++ on the world w/o a standard set of classes. (where as Eiffel, et. al. did) The ISO C++ standards committee realized this and decided to come up with a standard set of basic C++ data structures. ATT's iostream and HP Labs' STL (standard templet library) ended up becoming part of this standard set. Thus libg++ classes are a purely FSF class library that shouldn't be used for any new code development. The current libg++ only contains what was left after the ISO stdlibc++ stuff was gutted. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
I think that the goal should be to make KLDs work with all kinds of kernels. And the only place where this seems to be a problem is with zalloc and zfree. So it seems to me that one of the following could be done to solve it: a. make zalloc and zfree non-inline b. call zalloci and zfreei in code that can end up in KLDs c. call zalloci and zfreei everywhere where it's not performance-critical There are many potential problems with SMP kernels. Many of the inline functions in machine/cpufunc.h depend on SMP. We've already pessimised the usual (non-SMP) case by uninlining a few too many spl-related functions. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
Thus libg++ classes are a purely FSF class library that shouldn't be used for any new code development. The current libg++ only contains what was left after the ISO stdlibc++ stuff was gutted. Thanks for the explanation - that makes things much clearer. So, I guess we shoot for libstdc++ as the minimum requirements and perhaps provide libg++ as well (not necessarily initially) just for the convenience of those porting code from environments where the GNU library functions were used. I've just built the world and kernel from egcs-2.91.62 and it seems to work pretty well. I haven't really stress the system all that much yet, but it hasn't misbehaved in any way yet. - Jrodan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
guess we shoot for libstdc++ as the minimum requirements and perhaps provide libg++ as well (not necessarily initially) just for the Just make libg++ a port. :-) -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: panic: zone: entry not free
Bruce Evans b...@zeta.org.au writes: I think that the goal should be to make KLDs work with all kinds of kernels. And the only place where this seems to be a problem is with zalloc and zfree. So it seems to me that one of the following could be done to solve it: a. make zalloc and zfree non-inline b. call zalloci and zfreei in code that can end up in KLDs c. call zalloci and zfreei everywhere where it's not performance-critical There are many potential problems with SMP kernels. Many of the inline functions in machine/cpufunc.h depend on SMP. We've already pessimised the usual (non-SMP) case by uninlining a few too many spl-related functions. So you think it would be bad to have zalloc and zfree as non-inline functions? That would mean that KLDs would be different depending on the options used to build the kernel and that KLDs would need some way of figuring out the these options. How should that be done? By installing opt_global.h after building the kernel? /assar To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
Jordan K. Hubbard wrote: I've just built the world and kernel from egcs-2.91.62 and it seems to work pretty well. I haven't really stress the system all that much yet, but it hasn't misbehaved in any way yet. - Jrodan Since 4.0 was only recently branched, now seems like a good time to start using egcs as the system compiler, even if things are a bit bumpy for a while. Many people who started using -current during the 2.X vs 3.0 time can use 3.X-stable without losing much, if anything. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
