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
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
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
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
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
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
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
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
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
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
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
%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
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.
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
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.
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
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.
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
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
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
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
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
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
...
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
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
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
[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
: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?
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
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
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
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 /
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
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
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%
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
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,
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
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
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
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
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
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.
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
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.
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
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
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
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
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
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
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
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 =
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
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
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
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
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
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
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
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
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)
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
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:
:
:
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
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
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
:
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,
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
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
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
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
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
73 matches
Mail list logo
