Re: aout support broken in gcc3
On Mon, Sep 02, 2002 at 12:42:47PM -0700, Julian Elischer wrote: On Mon, Sep 02, 2002 at 01:24:19PM -0400, Matthew Emmerton wrote: I thought it was part of the plan to drop all traces of a.out support in 5.x. Am I wrong? We should be *very* careful to accurately describe what is being suggested. I believe it is that 5.x a.out binaries not be supported. However, 2.x a.out binaries will be supported. This is different thatn drop all traces of a.out support. yes binary support will remain.. if you need to generate new ones (?) unpack a 2.2.6 system into a chroot tree (jail?) and make it there :-) *sigh* This *still* isn't clear what is being suggested. (also seen in other emails in this thread, just picked this one to repond to) This is what BDE said: Actually, I agree. Not having a clean break in FreeBSD-3 was very expensive. Support for running aout binaries and compatibility cruft to support old binaries should have been dropped too. This is NOT a toolchain issue he is talking about, but a kernel one. Please forget all about the toolchain issue. It is a non-issue. I and kan are the only ones that it has inconvinced. Everyone else has been able to totally ignore it. I'll probably do something about it next week. _The_ issue is to understand exactly what is being discussed about compatibility cruft to support old binaries should have been dropped tooQ. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
On Tue, 3 Sep 2002, David O'Brien wrote: This is NOT a toolchain issue he is talking about, but a kernel one. Please forget all about the toolchain issue. It is a non-issue. I and kan are the only ones that it has inconvinced. Everyone else has been able to totally ignore it. I'll probably do something about it next week. I think that the ability to run 2.2.6 binaries should remain. the ability to generate them or even debug them can be almost completely removed.. there are always other ways to do that (e.g. boot 2.2.6 in a vmware machine or run them in a chroot) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- === gnu/usr.bin/cc/cc1plus method.o: In function `use_thunk': method.o(.text+0x90c): undefined reference to `sparc_output_mi_thunk' *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/gnu/usr.bin/cc/cc1plus. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/gnu/usr.bin/cc. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: installworld broken
On Mon, 2 Sep 2002, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
M. Warner Losh [EMAIL PROTECTED] writes:
: I've had to add ex, touch and gencat to the installworld target. And
: I've still not manged to complete a installworld.
:
: anybody else see this?
Index: Makefile.inc1
===
RCS file: /home/imp/FreeBSD/CVS/src/Makefile.inc1,v
retrieving revision 1.303
diff -u -r1.303 Makefile.inc1
--- Makefile.inc1 23 Aug 2002 12:49:16 - 1.303
+++ Makefile.inc1 2 Sep 2002 18:51:38 -
@@ -371,9 +372,9 @@
#
distributeworld installworld: installcheck
mkdir -p ${INSTALLTMP}
- for prog in [ awk cat chflags chmod chown date echo egrep find grep \
- ln make mkdir mtree mv pwd_mkdb rm sed sh sysctl \
- test true uname wc zic; do \
+ for prog in [ awk cap_mkdb cat chflags chmod chown date echo ex \
+ egrep find gencat grep ln m4 make mkdir mtree mv pwd_mkdb rm \
+ sed sh sysctl test touch true uname wc zic; do \
cp `which $$prog` ${INSTALLTMP}; \
done
cd ${.CURDIR}; ${IMAKE} re${.TARGET:S/world$//}
I plan to commit this change soon unless somone objects. Yes, all the
programs I added are necessary. Why they are now and not before, I
know not.
I object :-). This change shoots the messenger. You apparently have
timestamp problems which result in trmcap being rebuilt at install
time. Building at install time should fail.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
GCC being able to produce a.out format binaries has nothing to do with the ability of a Lisp or Prolog to compile to object files, Correct. and read such, whether said object files be a.out or ELF or COFF or PECOFF or Mach-O or ... False. As I said, I have systems that read a.out format object files and they would need to be ported to read ELF object files instead. Furthermore, they write themselves out (after loading object files) in a.out format, and would need to be ported to write themselves out in ELF format. -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: installworld broken
On (2002/09/02 12:44), Steve Kargl wrote: : I've had to add ex, touch and gencat to the installworld target. And : I've still not manged to complete a installworld. : : anybody else see this? Strange, I just did a make buildworld ... mergermaster sequence and I did not need the three utilities you mention. Why is that strange? You're talking about everything up to but not including installworld. Warner's talking about installworld. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2.1-pre imported
On 1 Sep, Alexander Kabaev wrote: GCC 3.2.1-pre is now in the tree. Please let me know if you see any problems recompiling your world/kernel. I haven't seen any other reports of this problem. I'm upgrading from a September 1st version of -current. cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr/obj/usr/src/i386/usr\ -I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I.-D__FBSDID=__RCSID -c /usr/src/contrib/gcc/c-decl.c cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr/obj/usr/src/i386/usr\ -I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I.-D__FBSDID=__RCSID -static -o cc1 main.o c-parse+%DIKED.o c-lang.o c-decl.o /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libcc_int.a /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libcc_int.a(i386.o): In function `ix86_expand_int_movcc': i386.o(.text+0x7bf5): undefined reference to `gen_int_mode' *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cc1. *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Page faults from bento cluster (Re: Problems reading vmcores)
On 31 Aug, Kris Kennaway wrote:
Another one. I have the cores if anyone needs to look at
them..otherwise I'll stop posting these for now.
Kris
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x4
fault code = supervisor read, page not present
#6 0xc0399a48 in calltrap () at {standard input}:98
#7 0xc021d91f in exec_elf32_imgact (imgp=0xda326bb4) at imgact_elf.c:607
#8 0xc022a9a2 in execve (td=0xc484c240, uap=0xda326d10)
at /usr/src/sys/kern/kern_exec.c:280
#9 0xc03a8a31 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135022716, tf_esi = 0, tf_ebp =
-1077940704, tf_isp = -634229388, tf_ebx = 135022736, tf_edx = 135022736, tf_ecx =
135022895, tf_eax = 59, tf_trapno = 12, tf_err = 2, tf_eip = 134697908, tf_cs = 31,
tf_eflags = 659, tf_esp = -1077940748, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1050
#10 0xc0399a9d in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
Line 607 is the inner if statement in the loop below:
/* If the executable has a brand, search for it in the brand list. */
if (brand_info == NULL) {
for (i = 0; i MAX_BRANDS; i++) {
Elf_Brandinfo *bi = elf_brand_list[i];
if (bi != NULL
(hdr-e_ident[EI_OSABI] == bi-brand
|| 0 ==
strncmp((const char *)hdr-e_ident[OLD_EI_BRAND],
bi-compat_3_brand, strlen(bi-compat_3_brand {
brand_info = bi;
break;
}
}
}
Structure member compat_3_brand is at offset 4, but I don't see how we
could be getting that far because of the 'bi != NULL' check.
Can you point gdb at the core file and print the values of bi and hdr?
BTW, this code has changed a lot since your kernel was generated.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
cvsup10 broken (was: Re: HEADS UP: GCC 3.2.1-pre imported)
It appears that the problem is that cvsup10 is sick. It doesn't have a complete set of the gcc updates. I was only getting rev 1.2 of emit-rtl.c, but rev 1.3 was committed 36 hours ago. I got the correct version of that file plus a bunch of other stuff when I switched to cvsup13. On 3 Sep, Don Lewis wrote: On 1 Sep, Alexander Kabaev wrote: GCC 3.2.1-pre is now in the tree. Please let me know if you see any problems recompiling your world/kernel. I haven't seen any other reports of this problem. I'm upgrading from a September 1st version of -current. cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr/obj/usr/src/i386/usr\ -I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I. -D__FBSDID=__RCSID -c /usr/src/contrib/gcc/c-decl.c cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr/obj/usr/src/i386/usr\ -I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I. -D__FBSDID=__RCSID -static -o cc1 main.o c-parse+%DIKED.o c-lang.o c-decl.o /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libcc_int.a /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libcc_int.a(i386.o): In function `ix86_expand_int_movcc': i386.o(.text+0x7bf5): undefined reference to `gen_int_mode' *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cc1. *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/var/tmp/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- === usr.bin/getconf Virtual memory exhausted in `operator new' *** Error code 1 Stop in /var/tmp/des/src/usr.bin/getconf. *** Error code 1 Stop in /var/tmp/des/src/usr.bin. *** Error code 1 Stop in /var/tmp/des/src. *** Error code 1 Stop in /var/tmp/des/src. *** Error code 1 Stop in /var/tmp/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
On Tue, 3 Sep 2002, David O'Brien wrote: On Mon, Sep 02, 2002 at 12:42:47PM -0700, Julian Elischer wrote: yes binary support will remain.. if you need to generate new ones (?) unpack a 2.2.6 system into a chroot tree (jail?) and make it there :-) *sigh* This *still* isn't clear what is being suggested. (also seen in other emails in this thread, just picked this one to repond to) This is what BDE said: Actually, I agree. Not having a clean break in FreeBSD-3 was very expensive. Support for running aout binaries and compatibility cruft to support old binaries should have been dropped too. This is NOT a toolchain issue he is talking about, but a kernel one. Please forget all about the toolchain issue. It is a non-issue. I and kan are the only ones that it has inconvinced. Everyone else has been able to totally ignore it. I'll probably do something about it next week. _The_ issue is to understand exactly what is being discussed about compatibility cruft to support old binaries should have been dropped tooQ. Well, I meant everything (large parts of COMPAT_43, and kernel support for aout...). I was half joking about the kernel support. It would have been very painful to drop it in 3.0R. Now it seems to be too late to even think about dropping it for 5.0R. However, we should start deprecating it more, and I think some of the COMPAT_43 stuff is a better/ easier place to start than kern/imgact_aout.c. Most of it is probably only used by old aout binaries. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Tue, 3 Sep 2002 04:23:39 -0700 (PDT) Dag-Erling Smorgrav [EMAIL PROTECTED] wrote: === usr.bin/getconf Virtual memory exhausted in `operator new' *** Error code 1 This one I can reproduce. Will fix soon. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: internal compiler error with gcc 3.2
On 2002-09-02 08:52 +, Steve Kargl wrote: To test gcc 3.2, I've been updating all of my installed ports. It appears gcc 3.2 is having problems with libiconv-1.8_1. It doesn't here. I've used my own meta-port to install all the usual stuff I want to have around, yesterday. The installation of libiconv stressed the machine a bit at one point (I think it was during compiling iconv.c that is also giving you problems) but it went on and eventually worked without problems. charon@hades[14:58]/home/charon$ pkg_info | grep libiconv libiconv-1.8_1 A character set conversion library charon@hades[14:58]/home/charon$ gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.2.1 [FreeBSD] 20020901 (prerelease) cc -I. -I. -I../include -I./../include -I/usr/local/include -O -pipe -march=athlon -c ./iconv.c -fPIC -DPIC -o .libs/iconv.lo Are you sure you're not hitting faulty memory or something? -- FreeBSD: The Power to Serve -- http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: internal compiler error with gcc 3.2
Giorgos Keramidas wrote: On 2002-09-02 08:52 +, Steve Kargl wrote: To test gcc 3.2, I've been updating all of my installed ports. It appears gcc 3.2 is having problems with libiconv-1.8_1. It doesn't here. cc -I. -I. -I../include -I./../include -I/usr/local/include -O -pipe -march=athlon -c ./iconv.c -fPIC -DPIC -o .libs/iconv.lo ^ Discussed already... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: installworld broken
On Tue, Sep 03, 2002 at 09:50:55AM +0200, Sheldon Hearn wrote: On (2002/09/02 12:44), Steve Kargl wrote: : I've had to add ex, touch and gencat to the installworld target. And : I've still not manged to complete a installworld. : : anybody else see this? Strange, I just did a make buildworld ... mergermaster sequence and I did not need the three utilities you mention. Why is that strange? You're talking about everything up to but not including installworld. Warner's talking about installworld. :-) Sigh. I said 'make buildworld ... mergemaster sequence'. I assume people running -current would understand the use of ... and the word sequence to mean make buildworld make buildkernel make installkernel mergemaster -p reboot make installworld mergemaster -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
Julian Elischer wrote: On Tue, 3 Sep 2002, David O'Brien wrote: This is NOT a toolchain issue he is talking about, but a kernel one. Please forget all about the toolchain issue. It is a non-issue. I and kan are the only ones that it has inconvinced. Everyone else has been able to totally ignore it. I'll probably do something about it next week. I think that the ability to run 2.2.6 binaries should remain. So, you could live with 'options COMPAT_AOUT' or 'kldload i386_aout' or something like that? the ability to generate them or even debug them can be almost completely removed.. there are always other ways to do that (e.g. boot 2.2.6 in a vmware machine or run them in a chroot) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Tue, Sep 03, 2002 at 07:59:18AM -0400, Alexander Kabaev wrote: On Tue, 3 Sep 2002 04:23:39 -0700 (PDT) Dag-Erling Smorgrav [EMAIL PROTECTED] wrote: === usr.bin/getconf Virtual memory exhausted in `operator new' *** Error code 1 This one I can reproduce. Will fix soon. I was able to build/install world yesterday on alpha, but I get the same error message now with libiconv: [69]cicely9# /usr/bin/gperf -t -L ANSI-C -H aliases_hash -N aliases_lookup -G -W aliases -7 -C -k '1,3-11,$' -i 1 lib/aliases.gperf lib/aliases.h Virtual memory exhausted in `operator new' Exit 1 [70]cicely9# Do you think this is the same reason? -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Tue, 3 Sep 2002 16:56:52 +0200 Bernd Walter [EMAIL PROTECTED] wrote: Do you think this is the same reason? Yes. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvsup10 broken (was: Re: HEADS UP: GCC 3.2.1-pre imported)
Don Lewis wrote: It appears that the problem is that cvsup10 is sick. It doesn't have a complete set of the gcc updates. I was only getting rev 1.2 of emit-rtl.c, but rev 1.3 was committed 36 hours ago. I got the correct version of that file plus a bunch of other stuff when I switched to cvsup13. Argh. Out of disk space. Fixing now. On 3 Sep, Don Lewis wrote: On 1 Sep, Alexander Kabaev wrote: GCC 3.2.1-pre is now in the tree. Please let me know if you see any problems recompiling your world/kernel. I haven't seen any other reports of this problem. I'm upgrading from a September 1st version of -current. cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr/obj/usr/src/i386/usr\ -I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/ gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../../co ntrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I. -D__FBSDID=__RCSID -c /usr/src/contrib/gcc/c-decl.c cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr/obj/usr/src/i386/usr\ -I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/ gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../../co ntrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I. -D__FBSDID=__RCSID -static -o cc1 main.o c-parse+%DIKED.o c-lang.o c-de cl.o /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libcc_int.a /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libcc_int.a(i386 .o): In function `ix86_expand_int_movcc': i386.o(.text+0x7bf5): undefined reference to `gen_int_mode' *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cc1. *** Error code 1 Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Alexander Kabaev wrote:
On Tue, 3 Sep 2002 04:23:39 -0700 (PDT)
Dag-Erling Smorgrav [EMAIL PROTECTED] wrote:
=== usr.bin/getconf
Virtual memory exhausted in `operator new'
*** Error code 1
This one I can reproduce. Will fix soon.
Here's a clue:
peter@beast[8:06am]~-130 cat foo.c
int main(int ac, char *av[])
{
char *a = new char[1];
}
peter@beast[8:07am]~-131 c++ -o foo foo.c
peter@beast[8:07am]~-132 ./foo
peter@beast[8:08am]~-133 c++ -static -o foo foo.c
peter@beast[8:08am]~-134 ./foo
Abort
peter@beast[8:09am]~-147 ktrace ./foo
Abort
peter@beast[8:09am]~-148 kdump
34729 ktrace RET ktrace 0
34729 ktrace CALL execve(0x11fff947,0x11fff758,0x11fff768)
34729 ktrace NAMI ./foo
34729 foo RET execve 0
34729 foo CALL readlink(0x12000a154,0x11fff628,0x3f)
34729 foo NAMI /etc/malloc.conf
34729 foo RET readlink -1 errno 2 No such file or directory
34729 foo CALL mmap(0,0x2000,0x3,0x1002,0x,0,0)
34729 foo RET mmap 1610612736/0x16000
34729 foo CALL break(0x12003)
34729 foo RET break -1 errno 12 Cannot allocate memory
...
versus dynamic:
peter@beast[8:10am]~-152 ktrace ./foo
peter@beast[8:11am]~-153 kdump | more
35056 ktrace RET ktrace 0
35056 ktrace CALL execve(0x11fff947,0x11fff758,0x11fff768)
35056 ktrace NAMI ./foo
35056 ktrace NAMI /usr/libexec/ld-elf.so.1
35056 foo RET execve 0
35056 foo CALL mmap(0,0x1590,0x3,0x1000,0x,0,0)
35056 foo RET mmap 1610792960/0x16002c000
35056 foo CALL munmap(0x16002c000,0x1590)
35056 foo RET munmap 0
35056 foo CALL __sysctl(0x11fff478,0x2,0x16012ccf8,0x11fff488,0,0)
35056 foo RET __sysctl 0
35056 foo CALL mmap(0,0x8000,0x3,0x1002,0x,0,0)
35056 foo RET mmap 1610792960/0x16002c000
[.. lots of ld.so stuff trimmed ...]
35056 foo CALL sigprocmask(0x3,0x16012d158,0)
35056 foo RET sigprocmask 0
35056 foo CALL readlink(0x16024204c,0x11fff628,0x3f)
35056 foo NAMI /etc/malloc.conf
35056 foo RET readlink -1 errno 2 No such file or directory
35056 foo CALL mmap(0,0x2000,0x3,0x1002,0x,0,0)
35056 foo RET mmap 1611612160/0x1600f4000
35056 foo CALL break(0x120014000)
35056 foo RET break 0
35056 foo CALL break(0x120018000)
35056 foo RET break 0
35056 foo CALL exit(0)
ie: we have this which works:
35056 foo CALL break(0x120014000)
35056 foo RET break 0
vs:
34729 foo CALL break(0x12003)
34729 foo RET break -1 errno 12 Cannot allocate memory
It doesn't appear to be a resource limit though:
peter@beast[8:17am]~-172 cat foo.c
char buf[100];
int main(int ac, char *av[])
{
char *a = new char[1];
}
peter@beast[8:17am]~-173 c++ -o foo foo.c
peter@beast[8:17am]~-174 ktrace ./foo
peter@beast[8:18am]~-175 kdump | grep break
36947 foo CALL break(0x120108000)
36947 foo RET break 0
36947 foo CALL break(0x12010c000)
36947 foo RET break 0
How strange..
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: installworld broken
Strange, I just did a make buildworld ... mergermaster sequence and I did not need the three utilities you mention. Why is that strange? You're talking about everything up to but not including installworld. Warner's talking about installworld. :-) Sigh. I said 'make buildworld ... mergemaster sequence'. I assume people running -current would understand the use of ... and the word sequence to mean Some build just do buildworld to make sure it compiles not needing to install it. Just for clarification in the future, saying make world sequence will get your exact point across as well as saying make kernel instead of make buildkernel -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Problems with building aic7xxx modules.
Hi Scott and Justin, I've been having a problem building the new aic7xxx modules on -CURRENT. The machine is: FreeBSD magma 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Mon Jun 24 22:50:04 SAST 2002 root@magma:/usr/obj/usr/src/sys/MAGMA i386 The error (make buildkernel) is: /usr/obj/usr/src/sys/MAGMA/modules/usr/src/sys/modules/aic7xxx/ahc/../aicasm/aicasm -I/usr/src/sys/modules/aic7xxx/ahc/../../../cam/scsi -I/usr/src/sys/modules/aic7xxx/ahc/../../../dev/aic7xxx -o aic7xxx_seq.h -r aic7xxx_reg.h -p aic7xxx_reg_print.c -i /usr/src/sys/modules/aic7xxx/ahc/../../../dev/aic7xxx/aic7xxx_osm.h /usr/src/sys/modules/aic7xxx/ahc/../../../dev/aic7xxx/aic7xxx.seq (null): Unable to malloc scope object *** Error code 70 Stop in /usr/src/sys/modules/aic7xxx/ahc. This only happens after a 'make buildworld'. Same error from Sunday's sources (pre-gcc3.2) and since then. This appears to be because the aicasm binary is built with the new toolchain and cannot run on my kernel/libraries. This binary is handled specially for the buildkernel target. I assume this needs the same 'build-tools' style processing as other binaries used in the build. It makes a directory /usr/obj/usr/src/sys/MAGMA/modules/usr/obj/usr/src/sys/MAGMA/modules/usr/src/sys/modules/aic7xxx/aicasm but doesn't put anything in it. Copying aicasm built for the kernel over the one built for the module appears to fix the problem. The aicasm binary built for the module is not cleaned as part of a regular 'make buildkernel'. I'll take a look at the infrastructure and see if I can come up with patches, but since this is fairly new, you guys might be able to solve it before me. Regards, -Jeremy -- FreeBSD - Because the best things in life are free... http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure - kernel is broken.
Alexander Kabaev wrote: On Tue, 3 Sep 2002 16:56:52 +0200 Bernd Walter [EMAIL PROTECTED] wrote: Do you think this is the same reason? Yes. Folks, it is a *kernel* problem: peter@ashburton[6:38pm]~-111 cc -v Using built-in specs. Configured with: FreeBSD/alpha system compiler Thread model: posix gcc version 3.1 [FreeBSD] 20020509 (prerelease) peter@ashburton[6:38pm]~-112 c++ -static -o foo foo.c peter@ashburton[6:39pm]~-113 ./foo Abort(core dumped) peter@ashburton[6:39pm]~-114 uname -a FreeBSD ashburton.netplex.com.au 5.0-CURRENT FreeBSD 5.0-CURRENT #15: Sat Aug 31 16:02:39 PDT 2002 [EMAIL PROTECTED]:/home/src/sys/alpha/compile/ASHBURTON alpha gcc-3.2.1 is not at fault. If it isn't kernel, it is library related. But Matt Dillon did commit a couple of changes in this area very recently. I think we should be looking around here: dillon 2002/06/25 17:29:28 PDT Modified files: sys/sys resource.h sys/vm vm_mmap.c vm_unix.c Log: Part I of RLIMIT_VMEM implementation. Implement core functionality for a new resource limit that covers a process's entire VM space, including mmap()'d space. (Part II will be additional code to check RLIMIT_VMEM during exec() but it needs more fleshing out). PR: kern/18209 Submitted by: Andrey Alekseyev [EMAIL PROTECTED], Dmitry Kim [EMAIL PROTECTED] MFC after: 7 days Revision ChangesPath 1.18 +3 -1 src/sys/sys/resource.h 1.149 +7 -0 src/sys/vm/vm_mmap.c 1.40 +5 -0 src/sys/vm/vm_unix.c dillon 2002/08/30 11:09:46 PDT Modified files: sys/kern imgact_elf.c sys/compat/svr4 svr4_misc.c svr4_resource.c Log: Implement data, text, and vmem limit checking in the elf loader and svr4 compat code. Clean up accounting for multiple segments. Part 1/2. Submitted by: Andrey Alekseyev [EMAIL PROTECTED] (with some modifications) MFC after: 3 days Revision ChangesPath 1.50 +2 -3 src/sys/compat/svr4/svr4_misc.c 1.11 +1 -1 src/sys/compat/svr4/svr4_resource.c 1.121 +33 -10src/sys/kern/imgact_elf.c Probably the later one, the timing is about right. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure - kernel is broken.
On Tue, Sep 03, 2002 at 09:01:07AM -0700, Peter Wemm wrote: Alexander Kabaev wrote: On Tue, 3 Sep 2002 16:56:52 +0200 Bernd Walter [EMAIL PROTECTED] wrote: Do you think this is the same reason? Yes. Folks, it is a *kernel* problem: peter@ashburton[6:38pm]~-111 cc -v Using built-in specs. Configured with: FreeBSD/alpha system compiler Thread model: posix gcc version 3.1 [FreeBSD] 20020509 (prerelease) peter@ashburton[6:38pm]~-112 c++ -static -o foo foo.c peter@ashburton[6:39pm]~-113 ./foo Abort(core dumped) peter@ashburton[6:39pm]~-114 uname -a FreeBSD ashburton.netplex.com.au 5.0-CURRENT FreeBSD 5.0-CURRENT #15: Sat Aug 31 16:02:39 PDT 2002 [EMAIL PROTECTED]:/home/src/sys/alpha/compile/ASHBURTON alpha gcc-3.2.1 is not at fault. If it isn't kernel, it is library related. But Matt Dillon did commit a couple of changes in this area very recently. I think we should be looking around here: dillon 2002/06/25 17:29:28 PDT Revision ChangesPath 1.18 +3 -1 src/sys/sys/resource.h 1.149 +7 -0 src/sys/vm/vm_mmap.c 1.40 +5 -0 src/sys/vm/vm_unix.c dillon 2002/08/30 11:09:46 PDT Revision ChangesPath 1.50 +2 -3 src/sys/compat/svr4/svr4_misc.c 1.11 +1 -1 src/sys/compat/svr4/svr4_resource.c 1.121 +33 -10src/sys/kern/imgact_elf.c Probably the later one, the timing is about right. I was running -current from 2002/08/11 before without any sign about this kind of problem. Building libiconv failed reproduceable for me, but booting an 2002/08/11 kernel made me build the port. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Another aic7xxx kernel build failure...
Another issue with 'aicasm': It breaks the following: * Vanilla install of 4.6-RELEASE (from CD-ROM) * Pull 5.0-CURRENT sources (as of 2 Sept 2002) * 'make buildworld' * 'make kernel' The kernel compile breaks when it tries to run aicasm, with a message about 'libc.so.5' not being available. It looks like aicasm is being compiled (and dynamically linked) against the new world (5.0-CURRENT), but then gets run in the currently-installed world (4.6-RELEASE). I worked around by manually compiling aicasm in the installed world (cd /aicasm make aicasm) and copying it into the /usr/obj tree. Then 'make kernel' was able to succeed. Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure - kernel is broken.
Bernd Walter wrote: On Tue, Sep 03, 2002 at 09:01:07AM -0700, Peter Wemm wrote: Alexander Kabaev wrote: On Tue, 3 Sep 2002 16:56:52 +0200 Bernd Walter [EMAIL PROTECTED] wrote: Do you think this is the same reason? Yes. Folks, it is a *kernel* problem: peter@ashburton[6:38pm]~-111 cc -v Using built-in specs. Configured with: FreeBSD/alpha system compiler Thread model: posix gcc version 3.1 [FreeBSD] 20020509 (prerelease) peter@ashburton[6:38pm]~-112 c++ -static -o foo foo.c peter@ashburton[6:39pm]~-113 ./foo Abort(core dumped) peter@ashburton[6:39pm]~-114 uname -a FreeBSD ashburton.netplex.com.au 5.0-CURRENT FreeBSD 5.0-CURRENT #15: Sat A ug 31 16:02:39 PDT 2002 [EMAIL PROTECTED]:/home/src/sys/a lpha/compile/ASHBURTON alpha gcc-3.2.1 is not at fault. If it isn't kernel, it is library related. But Matt Dillon did commit a couple of changes in this area very recently. I think we should be looking around here: dillon 2002/06/25 17:29:28 PDT Revision ChangesPath 1.18 +3 -1 src/sys/sys/resource.h 1.149 +7 -0 src/sys/vm/vm_mmap.c 1.40 +5 -0 src/sys/vm/vm_unix.c dillon 2002/08/30 11:09:46 PDT Revision ChangesPath 1.50 +2 -3 src/sys/compat/svr4/svr4_misc.c 1.11 +1 -1 src/sys/compat/svr4/svr4_resource.c 1.121 +33 -10src/sys/kern/imgact_elf.c Probably the later one, the timing is about right. I was running -current from 2002/08/11 before without any sign about this kind of problem. Building libiconv failed reproduceable for me, but booting an 2002/08/11 kernel made me build the port. Yes, imgact_elf.c rev 1.121 is the culprit. Reverting that change solves the problem. It should probably be backed out and un-MFC'ed. *definately* un-MFC'ed. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
On Tue, 3 Sep 2002, Peter Wemm wrote: Julian Elischer wrote: On Tue, 3 Sep 2002, David O'Brien wrote: This is NOT a toolchain issue he is talking about, but a kernel one. Please forget all about the toolchain issue. It is a non-issue. I and kan are the only ones that it has inconvinced. Everyone else has been able to totally ignore it. I'll probably do something about it next week. I think that the ability to run 2.2.6 binaries should remain. So, you could live with 'options COMPAT_AOUT' or 'kldload i386_aout' or something like that? for me that would be enough. Can't speak for others though.. as on -hackers or somewhere.. maybe even on -announce Announce: Planned removal of default support for a.out and see if anyone screams :-) the ability to generate them or even debug them can be almost completely removed.. there are always other ways to do that (e.g. boot 2.2.6 in a vmware machine or run them in a chroot) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
On Tue, 3 Sep 2002, Peter Wemm wrote: Julian Elischer wrote: On Tue, 3 Sep 2002, David O'Brien wrote: This is NOT a toolchain issue he is talking about, but a kernel one. Please forget all about the toolchain issue. It is a non-issue. I and kan are the only ones that it has inconvinced. Everyone else has been able to totally ignore it. I'll probably do something about it next week. I think that the ability to run 2.2.6 binaries should remain. So, you could live with 'options COMPAT_AOUT' or 'kldload i386_aout' or something like that? As long as I can set things up so that a chroot to an environment full of 2.2.6 binaries will still work, then I can still support sites with embedded 2.2.6 based things.. Others may find this a requirement too. the ability to generate them or even debug them can be almost completely removed.. there are always other ways to do that (e.g. boot 2.2.6 in a vmware machine or run them in a chroot) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure - kernel is broken.
: Building libiconv failed reproduceable for me, but booting an : 2002/08/11 kernel made me build the port. : :Yes, imgact_elf.c rev 1.121 is the culprit. Reverting that change solves :the problem. : :It should probably be backed out and un-MFC'ed. *definately* un-MFC'ed. : :Cheers, :-Peter :-- :Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Hold on, let me review the issue. Those changes were supposed to be low impact. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure - kernel is broken.
:
:Yes, imgact_elf.c rev 1.121 is the culprit. Reverting that change solves
:the problem.
:
:It should probably be backed out and un-MFC'ed. *definately* un-MFC'ed.
:
:Cheers,
:-Peter
:--
:Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
:All of this is for nothing if we don't go to the stars - JMS/B5
I have an alpha, let me try to reproduce this (it may take a while).
The datasize limit is fairly straight forward, either the failure
is for real or there is an accounting problem somewhere.
What happens if you replace this check in imgact_elf.c with a
printf of the conditional clauses instead of generating a failure?
+ if (data_size
+ imgp-proc-p_rlimit[RLIMIT_DATA].rlim_cur ||
+ text_size maxtsiz ||
+ data_size + text_size
+ imgp-proc-p_rlimit[RLIMIT_VMEM].rlim_cur) {
+ error = ENOMEM;
+ goto fail;
+ }
Does that unbreak it? That would tell us which clause is causing
the failure. You can probably do this faster then I can build
a new world and kernel for my alpha.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure - kernel is broken.
From the ktrace output it looks like the alpha is confused about
the datasize limit calculation. The program data appears to start
at the 4G mark so it is likely that the confusion is with the
'data_addr' variable whos calculation was changed slightly.
In that rev data_addr was set to the first data segment's address.
In the original code the data_addr was set to the last data segment's
address.
Try making the following change, from:
if (prot VM_PROT_WRITE) {
data_size += seg_size;
if (data_addr == 0)
data_addr = seg_addr;
} else {
text_size += seg_size;
if (text_addr == 0)
text_addr = seg_addr;
}
To:
if (prot VM_PROT_WRITE) {
data_size += seg_size;
data_addr = seg_addr;
} else {
text_size += seg_size;
if (text_addr == 0)
text_addr = seg_addr;
}
And see if that fixes the problem. I'm not sure why the alpha
is separating its first and last data segments by 4G of VM, some
debugging would be helpful:
if (prot VM_PROT_WRITE) {
printf(LOAD DATASEG %p %ld\n, (void *)seg_addr,
seg_size);
data_size += seg_size;
if (data_addr == 0)
data_addr = seg_addr;
} else {
printf(LOAD TEXTSEG %p %ld\n, (void *)seg_addr,
seg_size);
text_size += seg_size;
if (text_addr == 0)
text_addr = seg_addr;
}
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvsup10 broken (was: Re: HEADS UP: GCC 3.2.1-pre imported)
Peter Wemm [EMAIL PROTECTED] writes: Don Lewis wrote: It appears that the problem is that cvsup10 is sick. It doesn't have a complete set of the gcc updates. I was only getting rev 1.2 of emit-rtl.c, but rev 1.3 was committed 36 hours ago. I got the correct version of that file plus a bunch of other stuff when I switched to cvsup13. Argh. Out of disk space. Fixing now. This also happened to be the problem for sparc64 tinderbox. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure - kernel is broken.
On Tue, 2002/09/03 at 09:37:14 -0700, Peter Wemm wrote:
Bernd Walter wrote:
On Tue, Sep 03, 2002 at 09:01:07AM -0700, Peter Wemm wrote:
I was running -current from 2002/08/11 before without any sign about
this kind of problem.
Building libiconv failed reproduceable for me, but booting an
2002/08/11 kernel made me build the port.
Yes, imgact_elf.c rev 1.121 is the culprit. Reverting that change solves
the problem.
I have attached a patch which, I believe, should fix the problem. I
have no alpha box, so I cannot test kernel patches beyond compiling
them, so be warned, all below is just a theory, and the patch might of
course be broken (so keep kernel.old around :).
The problem was caused by the fact that on static executable, the text
segment is writable on alpha, so the heuristic prot VM_PROT_WRITE in
the ELF image activator will regard everything as a data segment. This
has the (non-fatal) effect that the program text size is regarded to
be 0.
Much more fatal, however, is that obreak() assumes that all data
segments start on consecutive pages (see below). Newer binutils will
however place the data segment on the next 64k page at the same offset
after the text segment (probably to make it easier for the OS to use
super pages), so that holes of more than a page size can occur.
obreak() will calculate the heap end address by taking the start
of the program data and adding the current data size.
The data size of a process is initially set by the image activator;
the ELF one sums up the number of 8k-pages actually needed to hold the
data. Now, if a hole happens to be between the segments that the
image activator thinks to hold data, (start address + number of used
pages) does of course not suffice to calculate the end address any
more.
The result is that the vm_map_insert() in obreak() can collide with
program segments when trying to insert a mapping starting with the old
address (that was calculated incorrectly), so it will fail, causing
ENOMEM to be returned.
For dynamic executables, this does not occur because the text segment
is not writable; the dynamic section, which is writable and executable
(because of the plt) starts after the hole and is directly followed by
the rest of the data.
The attached patch does just change the heuristics used to detect
text segments to look for executable segments (using an idea from
Peter). This results in the fact that dynamic section is viewed as
text, which should not break anything.
This way, it should be possible to avoid the hole currently; a real
fix would be to add a new vmspace field to represent the heap size
including holes which could then be used by obreak(), while vm_dsize
would only be used for statistics (which is however difficult to
maintain when shrinking below the initial size with brk()).
Can somebody who is feeling adventurous and has an alpha box please
test whether this fixes it for now?
Thanks,
- Thomas
--
Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/
[EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
Index: kern/imgact_elf.c
===
RCS file: /home/ncvs/src/sys/kern/imgact_elf.c,v
retrieving revision 1.124
diff -u -r1.124 imgact_elf.c
--- kern/imgact_elf.c 2 Sep 2002 17:27:30 - 1.124
+++ kern/imgact_elf.c 3 Sep 2002 17:10:21 -
@@ -738,14 +738,14 @@
* to distinguish between the two for the purpose
* of limit checking and vmspace fields.
*/
- if (prot VM_PROT_WRITE) {
- data_size += seg_size;
- if (data_addr == 0)
- data_addr = seg_addr;
- } else {
+ if (prot VM_PROT_EXECUTE) {
text_size += seg_size;
if (text_addr == 0)
text_addr = seg_addr;
+ } else {
+ data_size += seg_size;
+ if (data_addr == 0)
+ data_addr = seg_addr;
}
/*
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
On Tue, 3 Sep 2002 09:31:52 -0700 (PDT), Julian Elischer [EMAIL PROTECTED] said: As long as I can set things up so that a chroot to an environment full of 2.2.6 binaries will still work, then I can still support sites with embedded 2.2.6 based things.. Others may find this a requirement too. I think more people probably care about this: /usr/local/lib/netscape/communicator-4.7.us.bin: FreeBSD/i386 compact demand paged dynamically linked executable -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure - kernel is broken.
:The attached patch does just change the heuristics used to detect :text segments to look for executable segments (using an idea from :Peter). This results in the fact that dynamic section is viewed as :text, which should not break anything. :This way, it should be possible to avoid the hole currently; a real :fix would be to add a new vmspace field to represent the heap size :including holes which could then be used by obreak(), while vm_dsize :would only be used for statistics (which is however difficult to :maintain when shrinking below the initial size with brk()). : :Can somebody who is feeling adventurous and has an alpha box please :test whether this fixes it for now? : :Thanks, : - Thomas Excellent Thomas! Thanks for tracking this down. Your patch looks far better then mine if the circumstances of the failure are as you believe. As soon as we get verification that your patch solves the problem, I will commit / MFC cycle it. I am also still somewhat worried about the data segment start address and I am wondering if I should remove the if (data_addr == 0) and instead unconditionally set data_addr to the last data segment loaded (which is what the original code did). -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure - kernel is broken.
On 03-Sep-2002 Thomas Moestl wrote: On Tue, 2002/09/03 at 09:37:14 -0700, Peter Wemm wrote: Bernd Walter wrote: On Tue, Sep 03, 2002 at 09:01:07AM -0700, Peter Wemm wrote: I was running -current from 2002/08/11 before without any sign about this kind of problem. Building libiconv failed reproduceable for me, but booting an 2002/08/11 kernel made me build the port. Yes, imgact_elf.c rev 1.121 is the culprit. Reverting that change solves the problem. Can somebody who is feeling adventurous and has an alpha box please test whether this fixes it for now? Nope, if anything it's now worse. :( We should perhaps revert this change in -stable until we can get it to work in -current. FWIW, with the patch all sorts of programs no longer work including find, rpc.lockd, cron, sendmail, getty, etc., not just static c++ programs. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
KDE broken on CURRENT (with gcc3.2)
Hi all, I reported this to kde@, but got no answer back (yet). I deleted _ALL_ ports, removed /usr/local/include, removed /usr/X11R6. I also removed /usr/include and reinstalled a fresh compiled world. X11R6 and QT are fresh built from sources. Same code compiles fine with gcc3.1. Can anybody with C++ knowledge help here ? ports/audio/arts c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../mcop -I/usr/local/include -I/usr/X11R6/inc lude -I../libltdl -pthread -DQT_THREAD_SUPPORT -L/usr/local/lib -I/usr/local/inc lude -I/usr/local/include -I/usr/X11R6/include -D_THREAD_SAFE -DNDEBUG -DNO_DEBU G -O2 -O -pipe -fno-exceptions -fno-check-new -ftemplate-depth-99 -c qiomanager. cc -MT qiomanager.lo -MD -MP -MF .deps/qiomanager.TPlo -fPIC -DPIC -o .libs/qio manager.o In file included from qiomanager.cc:308: qiomanager_p.moc:28: no `void Arts::QIOWatch::initMetaObject()' member function declared in class `Arts::QIOWatch' qiomanager_p.moc: In member function `void Arts::QIOWatch::initMetaObject()': qiomanager_p.moc:32: `badSuperclassWarning' undeclared (first use this function) qiomanager_p.moc:32: (Each undeclared identifier is reported only once for each function it appears in.) qiomanager_p.moc:34: no method `QObject::initMetaObject' qiomanager_p.moc:39: `struct QMetaData' has no member named `ptr' qiomanager_p.moc:39: `QMember' undeclared (first use this function) qiomanager_p.moc:39: syntax error before `)' token qiomanager_p.moc:42: no matching function for call to `QMetaObject::QMetaObject (const char[9], const char[8], QMetaData*, int, int, int)' /usr/X11R6/include/qmetaobject.h:226: candidates are: QMetaObject::QMetaObject(const QMetaObject) /usr/X11R6/include/qmetaobject.h:147: QMetaObject::QMetaObject(const char*, QMetaObject*, const QMetaData*, int, const QMetaData*, int, const QMetaProperty*, int, const QMetaEnum*, int, const QClassInfo*, int) In file included from qiomanager.cc:308: qiomanager_p.moc: At global scope: qiomanager_p.moc:54: no `void Arts::QTimeWatch::initMetaObject()' member function declared in class `Arts::QTimeWatch' qiomanager_p.moc: In member function `void Arts::QTimeWatch::initMetaObject()': qiomanager_p.moc:60: no method `QObject::initMetaObject' qiomanager_p.moc:65: `struct QMetaData' has no member named `ptr' qiomanager_p.moc:65: syntax error before `)' token qiomanager_p.moc:68: no matching function for call to `QMetaObject::QMetaObject (const char[11], const char[8], QMetaData*, int, int, int)' /usr/X11R6/include/qmetaobject.h:226: candidates are: QMetaObject::QMetaObject(const QMetaObject) /usr/X11R6/include/qmetaobject.h:147: QMetaObject::QMetaObject(const char*, QMetaObject*, const QMetaData*, int, const QMetaData*, int, const QMetaProperty*, int, const QMetaEnum*, int, const QClassInfo*, int) gmake[2]: *** [qiomanager.lo] Error 1 gmake[2]: Leaving directory `/usr/ports/audio/arts/work/arts-1.0.3/qtmcop' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/audio/arts/work/arts-1.0.3' gmake: *** [all-recursive-am] Error 2 *** Error code 2 ports/devel/fam --- c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DCONFIG_ETC_CONFIG_PATH=\/usr/lo cal/etc/fam.conf\-O -pipe -c RPC_TCP_Connector.c++ c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DCONFIG_ETC_CONFIG_PATH=\/usr/lo cal/etc/fam.conf\-O -pipe -c Scanner.c++ c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DCONFIG_ETC_CONFIG_PATH=\/usr/lo cal/etc/fam.conf\-O -pipe -c Scheduler.c++ Scheduler.c++:37: uninitialized const member `Scheduler::IOTypeInfo::iotype' Scheduler.c++:38: uninitialized const member `Scheduler::IOTypeInfo::iotype' gmake[2]: *** [Scheduler.o] Error 1 gmake[2]: Leaving directory `/usr/ports/devel/fam/work/fam-2.6.8/fam' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/devel/fam/work/fam-2.6.8' gmake: *** [all-recursive-am] Error 2 *** Error code 2 Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure - kernel is broken.
On Tue, 2002/09/03 at 15:11:06 -0400, John Baldwin wrote:
On 03-Sep-2002 Thomas Moestl wrote:
On Tue, 2002/09/03 at 09:37:14 -0700, Peter Wemm wrote:
Bernd Walter wrote:
On Tue, Sep 03, 2002 at 09:01:07AM -0700, Peter Wemm wrote:
I was running -current from 2002/08/11 before without any sign about
this kind of problem.
Building libiconv failed reproduceable for me, but booting an
2002/08/11 kernel made me build the port.
Yes, imgact_elf.c rev 1.121 is the culprit. Reverting that change solves
the problem.
Can somebody who is feeling adventurous and has an alpha box please
test whether this fixes it for now?
Nope, if anything it's now worse. :( We should perhaps revert this
change in -stable until we can get it to work in -current. FWIW, with
the patch all sorts of programs no longer work including find,
rpc.lockd, cron, sendmail, getty, etc., not just static c++ programs.
Thanks for testing, and sorry!
This time, I broke dynmically linked programs :)
It turns out that only C++ programs actually had their text segments
mapped writable; dynamically linked programs have their data segment
mapped executable though (contrary to what I said before, the PLT is
actually included in the data segment, sorry). So, protections cannot
be used to discriminate between text and data. I have attached a a new
workaround patch that uses the old method to find the text segment
again (i.e. finding the entry point), and treats everything else as
data. This time it's tested (thanks to jhb) and actually seems to
work.
- Thomas
--
Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/
[EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
Index: imgact_elf.c
===
RCS file: /home/ncvs/src/sys/kern/imgact_elf.c,v
retrieving revision 1.124
diff -u -r1.124 imgact_elf.c
--- imgact_elf.c2 Sep 2002 17:27:30 - 1.124
+++ imgact_elf.c3 Sep 2002 19:11:58 -
@@ -734,18 +734,20 @@
phdr[i].p_vaddr - seg_addr);
/*
-* Is this .text or .data? Use VM_PROT_WRITE
-* to distinguish between the two for the purpose
-* of limit checking and vmspace fields.
+* Check whether the entry point is in this segment
+* to determine whether to count is as text or data.
+* XXX: this needs to be done better!
*/
- if (prot VM_PROT_WRITE) {
+ if (hdr-e_entry = phdr[i].p_vaddr
+ hdr-e_entry (phdr[i].p_vaddr +
+ phdr[i].p_memsz)) {
+ text_size = seg_size;
+ text_addr = seg_addr;
+ entry = (u_long)hdr-e_entry;
+ } else {
data_size += seg_size;
if (data_addr == 0)
data_addr = seg_addr;
- } else {
- text_size += seg_size;
- if (text_addr == 0)
- text_addr = seg_addr;
}
/*
@@ -762,12 +764,6 @@
goto fail;
}
- /* Does the entry point belong to this segment? */
- if (hdr-e_entry = phdr[i].p_vaddr
- hdr-e_entry (phdr[i].p_vaddr +
- phdr[i].p_memsz)) {
- entry = (u_long)hdr-e_entry;
- }
break;
case PT_PHDR: /* Program header table info */
proghdr = phdr[i].p_vaddr;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
* De: Richard Tobin [EMAIL PROTECTED] [ Data: 2002-09-03 ] [ Subjecte: Re: aout support broken in gcc3 ] GCC being able to produce a.out format binaries has nothing to do with the ability of a Lisp or Prolog to compile to object files, Correct. and read such, whether said object files be a.out or ELF or COFF or PECOFF or Mach-O or ... False. As I said, I have systems that read a.out format object files and they would need to be ported to read ELF object files instead. Furthermore, they write themselves out (after loading object files) in a.out format, and would need to be ported to write themselves out in ELF format. Where exactly does GCC fit into the mix, making this impossible? -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
fsck cannot find superblock
Hi, with 'uncommon' block sizes fsck seems to have problems finding the superblock: # newfs -i 10240 -b 4096 -f 512 /dev/ad1d Reduced frags per cylinder group from 26208 to 26200 to enlarge last cyl group /dev/ad1d: 409.6MB (838860 sectors) block size 4096, fragment size 512 using 33 cylinder groups of 12.79MB, 3275 blks, 1312 inodes. super-block backups (for fsck -b #) at: 32, 26232, 52432, 78632, 104832, 131032, 157232, 183432, 209632, 235832, 262032, 288232, 314432, 340632, 366832, 393032, 419232, 445432, 471632, 497832, 524032, 550232, 576432, 602632, 628832, 655032, 681232, 707432, 733632, 759832, 786032, 812232, 838432 # fsck /dev/ad1d ** /dev/ad1d Cannot find file system superblock LOOK FOR ALTERNATE SUPERBLOCKS? [yn] n If I type 'y' fsck will find an alternate superblock at 16 (not 32, as printed during newfs). The number of inodes, fragment size don't seem to have an impact, only block size. No problems with block size of 8192 though. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
CURRENT unstable during heavy file system I/O
Hi, since some months now my -CURRENT is very unstable during heavy file system activity (parallel accesses while deleting large subdirectories). Today, I ran the following command for simple cleanup of /usr/ports: # find /usr/ports -type d -name work -print | xargs rm -rf [Yes, I should have added an option -maxdepth 3]. During this cleanup the machine panic'd twice. I don't have a crash dump, only console output: Fatal double fault: eip = 0xc04304c8 esp = 0xd85e8fb8 ebp = 0xd85e980c panic: double fault Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db c syncing disks... panic: bwrite: buffer is not busy??? Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db c Uptime: 26m29s Dumping 127 MB ata0: resetting devices .. panic: bremfree: removing a buffer not on a queue Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db c Uptime: 26m29s Terminate ACPI Automatic reboot in 15 seconds - press a key on the console to abort gdb at address 0xc04304c8: Dump of assembler code for function bus_dmamap_load: 0xc0430340 bus_dmamap_load: push %ebp [...] 0xc04304b8 bus_dmamap_load+376: mov%eax,0xfff0(%ebp) 0xc04304bb bus_dmamap_load+379: mov0xffe4(%ebp),%edx 0xc04304be bus_dmamap_load+382: mov%edx,0xffe0(%ebp) 0xc04304c1 bus_dmamap_load+385: movl $0x1,0xffdc(%ebp) 0xc04304c8 bus_dmamap_load+392: movl $0x0,0x4(%edx) 0xc04304cf bus_dmamap_load+399: movl $0x0,0xffd4(%ebp) 0xc04304d6 bus_dmamap_load+406: lea0x0(%esi),%esi 0xc04304d9 bus_dmamap_load+409: lea0x0(%edi,1),%edi 0xc04304e0 bus_dmamap_load+416: mov0xfff0(%ebp),%ecx 0xc04304e3 bus_dmamap_load+419: mov%ecx,%eax 0xc04304e5 bus_dmamap_load+421: shr$0x16,%eax The panic bwrite: buffer is not busy??? is always the same. Daniel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: compiling kdelibs3 fails with -current's gcc 3.2
Hi, your patch to cp/cp-lang.c fixed the build of kdelibs3 for me. Thanks! Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure - kernel is broken.
On Tue, 2002/09/03 at 20:32:48 +0200, Thomas Moestl wrote: On Tue, 2002/09/03 at 11:21:05 -0700, Matthew Dillon wrote: I am also still somewhat worried about the data segment start address and I am wondering if I should remove the if (data_addr == 0) and instead unconditionally set data_addr to the last data segment loaded (which is what the original code did). That would only allow to shrink bss, but since that seems to be the traditional behaviour (and it's not likely that anybody would like to shrink away other segments), that would probably better. Huh, that should read data+bss for usual elf binaries which share the two in one segment (and there seems to be some code around in other places that expect binaries formed with only two PT_LOAD segments). Assuming that, setting data_addr conditionally or unconditionally should not make any difference, it will always be set for the first data PT_LOAD segment and there will be only one (the other one will be text). Sorry for the confusion, - Thomas -- Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/ [EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aic7xxx kernel build failure...
Well, I ended up unlinking it from the build and am installing now. Once I get a fresh world installed, I'll try and rebuild world again to see if the problem persists. Would you like me to get a ktrace of aicasm running before I rebuild world? -sc That would have been interesting. Agreed. I was going to grab it but after I did my install world it came back and said it had X instructions and that was it. :-/ Not the same (null) unable to malloc goo that I got earlier. I think this is just compiler and world flakiness from early aug. You can try supping your world to aug-05 and doing an update to todays world and you should (hopefully, crosses fingers) be able to repeat things (assuming it wasn't hardware dependent). -sc -- Sean Chittenden msg42574/pgp0.pgp Description: PGP signature
Re: alpha tinderbox failure - kernel is broken.
:
: Can somebody who is feeling adventurous and has an alpha box please
: test whether this fixes it for now?
:
:Nope, if anything it's now worse. :( We should perhaps revert this
:change in -stable until we can get it to work in -current. FWIW, with
:the patch all sorts of programs no longer work including find,
:rpc.lockd, cron, sendmail, getty, etc., not just static c++ programs.
:
:--
:
:John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
:Power Users Use the Power to Serve! - http://www.FreeBSD.org/
Lets try just reverting the algorithm, and keeping the RLIMIT
stuff intact. Here's the patch for -current. Please review.
-Matt
Index: imgact_elf.c
===
RCS file: /home/ncvs/src/sys/kern/imgact_elf.c,v
retrieving revision 1.124
diff -u -r1.124 imgact_elf.c
--- imgact_elf.c2 Sep 2002 17:27:30 - 1.124
+++ imgact_elf.c3 Sep 2002 21:11:01 -
@@ -734,20 +734,23 @@
phdr[i].p_vaddr - seg_addr);
/*
-* Is this .text or .data? Use VM_PROT_WRITE
-* to distinguish between the two for the purpose
-* of limit checking and vmspace fields.
+* Is this .text or .data? We can't use
+* VM_PROT_WRITE or VM_PROT_EXEC, it breaks the
+* alpha terribly and possibly does other bad
+* things so we stick with the address check.
*/
- if (prot VM_PROT_WRITE) {
- data_size += seg_size;
- if (data_addr == 0)
- data_addr = seg_addr;
+
+ /* Does the entry point belong to this segment? */
+ if (hdr-e_entry = phdr[i].p_vaddr
+ hdr-e_entry (phdr[i].p_vaddr +
+ phdr[i].p_memsz)) {
+ entry = (u_long)hdr-e_entry;
+ text_size = seg_size;
+ text_addr = seg_addr;
} else {
- text_size += seg_size;
- if (text_addr == 0)
- text_addr = seg_addr;
+ data_size = seg_size;
+ data_addr = seg_addr;
}
-
/*
* Check limits. It should be safe to check the
* limits after loading the segment since we do
@@ -762,12 +765,6 @@
goto fail;
}
- /* Does the entry point belong to this segment? */
- if (hdr-e_entry = phdr[i].p_vaddr
- hdr-e_entry (phdr[i].p_vaddr +
- phdr[i].p_memsz)) {
- entry = (u_long)hdr-e_entry;
- }
break;
case PT_PHDR: /* Program header table info */
proghdr = phdr[i].p_vaddr;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: aic7xxx kernel build failure...
cvsup earlier today. I just finished mergemaster'ing my upgrade from a May -CURRENT. I removed the offending line from sys/modules/Makefile, and set NOMOODULES=1. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KDE broken on CURRENT (with gcc3.2)
Folks, ports/audio/arts I got this one solved by rm /usr/ports. It was a stale patch :/ ports/devel/fam --- c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DCONFIG_ETC_CONFIG_PATH=\/usr/lo cal/etc/fam.conf\-O -pipe -c RPC_TCP_Connector.c++ c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DCONFIG_ETC_CONFIG_PATH=\/usr/lo cal/etc/fam.conf\-O -pipe -c Scanner.c++ c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DCONFIG_ETC_CONFIG_PATH=\/usr/lo cal/etc/fam.conf\-O -pipe -c Scheduler.c++ Scheduler.c++:37: uninitialized const member `Scheduler::IOTypeInfo::iotype' Scheduler.c++:38: uninitialized const member `Scheduler::IOTypeInfo::iotype' gmake[2]: *** [Scheduler.o] Error 1 gmake[2]: Leaving directory `/usr/ports/devel/fam/work/fam-2.6.8/fam' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/devel/fam/work/fam-2.6.8' gmake: *** [all-recursive-am] Error 2 *** Error code 2 Is still broken. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KDE broken on CURRENT (with gcc3.2)
On Tue, Sep 03, 2002 at 11:30:02PM +0200, Martin Blapp wrote: ports/devel/fam --- c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DCONFIG_ETC_CONFIG_PATH=\/usr/lo cal/etc/fam.conf\-O -pipe -c RPC_TCP_Connector.c++ c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DCONFIG_ETC_CONFIG_PATH=\/usr/lo cal/etc/fam.conf\-O -pipe -c Scanner.c++ c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DCONFIG_ETC_CONFIG_PATH=\/usr/lo cal/etc/fam.conf\-O -pipe -c Scheduler.c++ Scheduler.c++:37: uninitialized const member `Scheduler::IOTypeInfo::iotype' Scheduler.c++:38: uninitialized const member `Scheduler::IOTypeInfo::iotype' gmake[2]: *** [Scheduler.o] Error 1 gmake[2]: Leaving directory `/usr/ports/devel/fam/work/fam-2.6.8/fam' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/devel/fam/work/fam-2.6.8' gmake: *** [all-recursive-am] Error 2 *** Error code 2 Is still broken. That's not KDE domain, though. We only depend on FAM. regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KDE broken on CURRENT (with gcc3.2)
Hi, That's not KDE domain, though. We only depend on FAM. Of course ;-) But the arts problem I fixed - sigh - was a KDE problem. I just listed this one too. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure - kernel is broken.
Matthew Dillon wrote:
+ /* Does the entry point belong to this segment? */
+ if (hdr-e_entry = phdr[i].p_vaddr
+ hdr-e_entry (phdr[i].p_vaddr +
+ phdr[i].p_memsz)) {
+ entry = (u_long)hdr-e_entry;
+ text_size = seg_size;
+ text_addr = seg_addr;
} else {
+ data_size = seg_size;
+ data_addr = seg_addr;
}
I don't think we can do this (the last section), it is quite legal to have
more than one non-text PT_LOAD segment. if the last one was very small,
we'd end up with an artificially low 'data_size' which would make for
interesting RLIMIT_DATA enforcement.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure - kernel is broken.
: +data_addr = seg_addr; : } : :I don't think we can do this (the last section), it is quite legal to have :more than one non-text PT_LOAD segment. if the last one was very small, :we'd end up with an artificially low 'data_size' which would make for :interesting RLIMIT_DATA enforcement. : :Cheers, :-Peter :-- :Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Well, this represents a reversion to what the data and text calculations were before any of my commits. I think that the best bet is to revert that part of the calculation completely rather then revert it only half way. From what I understand there is usually only one data segment in an ELF binary anyway. I am also worried that the kernel may be using the vmspace data start and size in other ways and, really, the safest solution for now is to revert it so data_start + data_size yields the end of data in the last loaded data segment (which is also the highest addressed data segment according to the ELF spec). We can always put it back in later. I will also note that RLIMIT_DATA is not really all that useful a resource limit. It's there basically to protect against runaway malloc()s but it does not in any way limit the amount of memory a program actually uses since mmap() is not counted. RLIMIT_VMEM is the ultimate memory resource limit. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
TIOCSCTTY not implemented in linuxulator?
Hi
Does anyone know why TIOCSCTTY isn't implemented in compat/linux_ioctl.c?
The last change in this area was back in 1999 when the ioctl handling was
revamped, but this ioctl was not implemented. Do controlling terminals
work okay in the linuxulator?
Implementing this might solve a problem with Matlab, where it refuses to exit.
Matlab issues calls to two unimplemented ioctls on the tty side of a pty/tty
pair.
linux: 'ioctl' fd=4, cmd=0x1 ('',1) not implemented
linux: 'ioctl' fd=4, cmd=0x1 ('',1) not implemented
linux: 'ioctl' fd=4, cmd=0x540e ('T',14) not implemented
0x540e is TIOCSCTTY, and according to /compat/linux/usr/include/asm/ioctls.h
0x1 is TIOCSER_TEMT (Transmitter physically empty)?
I'm using
4.6-PRERELEASE
linux_base-6.1_1
linux_devtools-6.1
linux_kdump-1.4
Thanks
Duncan
--
Duncan Barclay | God smiles upon the little children,
[EMAIL PROTECTED] | the alcoholics, and the permanently stoned.
[EMAIL PROTECTED]| Steven King
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
False. As I said, I have systems that read a.out format object files and they would need to be ported to read ELF object files instead. Furthermore, they write themselves out (after loading object files) in a.out format, and would need to be ported to write themselves out in ELF format. Where exactly does GCC fit into the mix, making this impossible? They compile Lisp (etc) to a C file, which they compile (with gcc) to a .o file, then link against the running image (with /usr/libexec/aout/ld -A) to produce a relocated .o file, then read it in and look at its symbol table to find the entry points. So they need a C compiler that can generate a.out format .o files, and a linker that can link a.out format .o files against an a.out format executable. I'm quite expecting the answer yes, we've considered this and decided that the overhead of supporting it is to much, but I want to make sure that you realise that there are programs that will break. Long-time BSD users will not be surprised to know that Franz Lisp (the original BSD Franz Lisp, not the commercial Franz Inc product) is one of them. Incidentally, I know that the modern alternative to reading in .o files is to use shared libraries instead, but as far as I know there isn't any support for writing out an executable that has shared libraries mapped in (so that they don't have to be loaded, or even exist, when the program is started again). -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
On Tue, Sep 03, 2002 at 11:32:22PM +0100, Richard Tobin wrote: False. As I said, I have systems that read a.out format object files and they would need to be ported to read ELF object files instead. Furthermore, they write themselves out (after loading object files) in a.out format, and would need to be ported to write themselves out in ELF format. Where exactly does GCC fit into the mix, making this impossible? They compile Lisp (etc) to a C file, which they compile (with gcc) to ^^^ actually with as(1), because gcc is only generates assembler file, which is then translated into the object file by assembler (as). Assembler by itself is part of binutils, not a compiler suite. -Maxim a .o file, then link against the running image (with /usr/libexec/aout/ld -A) to produce a relocated .o file, then read it in and look at its symbol table to find the entry points. So they need a C compiler that can generate a.out format .o files, and a linker that can link a.out format .o files against an a.out format executable. I'm quite expecting the answer yes, we've considered this and decided that the overhead of supporting it is to much, but I want to make sure that you realise that there are programs that will break. Long-time BSD users will not be surprised to know that Franz Lisp (the original BSD Franz Lisp, not the commercial Franz Inc product) is one of them. Incidentally, I know that the modern alternative to reading in .o files is to use shared libraries instead, but as far as I know there isn't any support for writing out an executable that has shared libraries mapped in (so that they don't have to be loaded, or even exist, when the program is started again). -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KDE broken on CURRENT (with gcc3.2)
On Tue, Sep 03, 2002 at 02:29:12PM -0700, Will Andrews wrote: On Tue, Sep 03, 2002 at 11:30:02PM +0200, Martin Blapp wrote: ports/devel/fam --- c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DCONFIG_ETC_CONFIG_PATH=\/usr/lo cal/etc/fam.conf\-O -pipe -c RPC_TCP_Connector.c++ c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DCONFIG_ETC_CONFIG_PATH=\/usr/lo cal/etc/fam.conf\-O -pipe -c Scanner.c++ c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DCONFIG_ETC_CONFIG_PATH=\/usr/lo cal/etc/fam.conf\-O -pipe -c Scheduler.c++ Scheduler.c++:37: uninitialized const member `Scheduler::IOTypeInfo::iotype' Scheduler.c++:38: uninitialized const member `Scheduler::IOTypeInfo::iotype' gmake[2]: *** [Scheduler.o] Error 1 gmake[2]: Leaving directory `/usr/ports/devel/fam/work/fam-2.6.8/fam' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/devel/fam/work/fam-2.6.8' gmake: *** [all-recursive-am] Error 2 *** Error code 2 Is still broken. That's not KDE domain, though. We only depend on FAM. I'm the maintainer, Will. Since I don't have a -CURRENT system, is one of the hasta's set up to test -CURRENT patches on? I can make a good guess at it from looking at the code, but it'll need to be tested somewhere. Also, is gcc-3.2 on -CURRENT a supported configuration? -- AlanE KDE-FreeBSD Team (http://freebsd.kde.org/) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KDE broken on CURRENT (with gcc3.2)
On Tue, 2002-09-03 at 19:01, Alan E wrote: On Tue, Sep 03, 2002 at 02:29:12PM -0700, Will Andrews wrote: On Tue, Sep 03, 2002 at 11:30:02PM +0200, Martin Blapp wrote: ports/devel/fam --- c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DCONFIG_ETC_CONFIG_PATH=\/usr/lo cal/etc/fam.conf\-O -pipe -c RPC_TCP_Connector.c++ c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DCONFIG_ETC_CONFIG_PATH=\/usr/lo cal/etc/fam.conf\-O -pipe -c Scanner.c++ c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DCONFIG_ETC_CONFIG_PATH=\/usr/lo cal/etc/fam.conf\-O -pipe -c Scheduler.c++ Scheduler.c++:37: uninitialized const member `Scheduler::IOTypeInfo::iotype' Scheduler.c++:38: uninitialized const member `Scheduler::IOTypeInfo::iotype' gmake[2]: *** [Scheduler.o] Error 1 gmake[2]: Leaving directory `/usr/ports/devel/fam/work/fam-2.6.8/fam' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/devel/fam/work/fam-2.6.8' gmake: *** [all-recursive-am] Error 2 *** Error code 2 Is still broken. That's not KDE domain, though. We only depend on FAM. I'm the maintainer, Will. Since I don't have a -CURRENT system, is one of the hasta's set up to test -CURRENT patches on? I can make a good guess at it from looking at the code, but it'll need to be tested somewhere. Also, is gcc-3.2 on -CURRENT a supported configuration? gcc-3.2 is the new compiler in -CURRENT as of two days ago. Joe -- AlanE KDE-FreeBSD Team (http://freebsd.kde.org/) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- PGP Key : http://www.marcuscom.com/pgp.asc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
Where exactly does GCC fit into the mix, making this impossible? They compile Lisp (etc) to a C file, which they compile (with gcc) to ^^^ actually with as(1), because gcc is only generates assembler file, which is then translated into the object file by assembler (as). Assembler by itself is part of binutils, not a compiler suite. I suspect Richard Tobin was using the generally accepted meaning for a compiler as one that translates a source program into object code (machine language). In any case, it is cc1 that generates an assembly file. gcc is just a driver program that calls various subprograms. Richard's main point with which I totally agree is that please do not take away the ability to generate and grok a.out files *if at all possible*. A number of Lisp systems as well as Scheme one use ld -A friends to do what he described. In general, please do not break backward compatibility. meta-discussion Seems to me that most of the FreeBSD developers are not heavy 3rd part software users. Consequently they (the developers) do not realize that even when sources are available it is not always easy to update them to support changes that break old code -- due to lack of time or money or inability or inexperience to change the 3rd party software or whatever. When sources are not available, you are up the proverbial creek. You may say just continue running old freeBSD kernels but the constant stream of security fixes makes hard to justify doing that. IMHO what is needed is a strong voice for the *users* (along with hackers/developers) in influencing the direction FreeBSD takes -- right now if you don't hack FreeBSD code, you don't get listened to very much. This is like letting a builder build a house, or worse, letting an architect design a house without input from the people who are going to live in it [trust me, you want a 4000 sq ft house on your 4500 sq ft lot, with humongous walkin closets, tiny bedrooms, a big master bathroom with large french windows in the shower (so what if it is facing your neighbor's living room windows only 10 ft away)]. In a commercial setting it is the user who ultimately pays the development costs so they do get listened to (or the company dies). As an example, on a modern SGI machine you can still run 20 year old binaries -- providing such compatibility is a pain and not pretty but to long time users' their dusty decks are very valuable. Unfortunately there is no such direct back-pressure in the open source community and developers usually don't have a long term view. /meta-discussion To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KDE broken on CURRENT (with gcc3.2)
I can confirm that kde3 doesn't build on -CURRENT with gcc 3.2.1 as well, but it has never worked for me on gcc 3.1 either. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KDE broken on CURRENT (with gcc3.2)
I'm the maintainer, Will. Since I don't have a -CURRENT system, is one of the hasta's set up to test -CURRENT patches on? I can make a good guess at it from looking at the code, but it'll need to be tested somewhere. Also, is gcc-3.2 on -CURRENT a supported configuration? gcc-3.2 on -CURRENT is the compiler that is default. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fam broken on CURRENT (with gcc3.2)
On Tue, Sep 03, 2002 at 11:30:02PM +0200, Martin Blapp wrote: ports/devel/fam --- c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DCONFIG_ETC_CONFIG_PATH=\/usr/lo cal/etc/fam.conf\-O -pipe -c RPC_TCP_Connector.c++ c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DCONFIG_ETC_CONFIG_PATH=\/usr/lo cal/etc/fam.conf\-O -pipe -c Scanner.c++ c++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DCONFIG_ETC_CONFIG_PATH=\/usr/lo cal/etc/fam.conf\-O -pipe -c Scheduler.c++ Scheduler.c++:37: uninitialized const member `Scheduler::IOTypeInfo::iotype' Scheduler.c++:38: uninitialized const member `Scheduler::IOTypeInfo::iotype' gmake[2]: *** [Scheduler.o] Error 1 gmake[2]: Leaving directory `/usr/ports/devel/fam/work/fam-2.6.8/fam' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/devel/fam/work/fam-2.6.8' gmake: *** [all-recursive-am] Error 2 *** Error code 2 I have upgraded fam to 2.6.9. Please check if the problem still exists. Thanks. -- AlanE KDE-FreeBSD Team (http://freebsd.kde.org/) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KDE broken on CURRENT (with gcc3.2)
I am experiencing this behavior as well (can't compile kde3 with gcc 3.2.1 or 3.1). However, with Alexander Kabaev's gcc 3.2 patch to cp-lang.c, kdelibs compiles ok and I can get kdebase to install by doing a 'make -k install'. Not sure exactly what's broken in the process, but it seems usable so far. On Tue, 3 Sep 2002, Kenneth Culver ([EMAIL PROTECTED]) wrote: I can confirm that kde3 doesn't build on -CURRENT with gcc 3.2.1 as well, but it has never worked for me on gcc 3.1 either. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KDE broken on CURRENT (with gcc3.2)
On Wed, 4 Sep 2002 20:59:20 + Michael Johnson [EMAIL PROTECTED] wrote: I am experiencing this behavior as well (can't compile kde3 with gcc 3.2.1 or 3.1). However, with Alexander Kabaev's gcc 3.2 patch to cp-lang.c, kdelibs compiles ok and I can get kdebase to install by doing The patch is not mine. I extracted it from GCC FSF CVS repository. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
On 03-Sep-2002 Bakul Shah wrote: Where exactly does GCC fit into the mix, making this impossible? They compile Lisp (etc) to a C file, which they compile (with gcc) to ^^^ actually with as(1), because gcc is only generates assembler file, which is then translated into the object file by assembler (as). Assembler by itself is part of binutils, not a compiler suite. I suspect Richard Tobin was using the generally accepted meaning for a compiler as one that translates a source program into object code (machine language). In any case, it is cc1 that generates an assembly file. gcc is just a driver program that calls various subprograms. Richard's main point with which I totally agree is that please do not take away the ability to generate and grok a.out files *if at all possible*. A number of Lisp systems as well as Scheme one use ld -A friends to do what he described. In general, please do not break backward compatibility. meta-discussion Seems to me that most of the FreeBSD developers are not heavy 3rd part software users. Consequently they (the developers) do not realize that even when sources are available it is not always easy to update them to support changes that break old code -- due to lack of time or money or inability or inexperience to change the 3rd party software or whatever. When sources are not available, you are up the proverbial creek. You may say just continue running old freeBSD kernels but the constant stream of security fixes makes hard to justify doing that. You are blowing this out of proportion and not actually reading what people are proposing. So far, the comments are about removing a.out support from the base compiler and offering a.out binutils and gcc _as ports_. Thus, people who needed to work with a.out can still install a toolchain to work with, they just wouldn't use the toolchain in the base system. The toolchain in the base system would then be easier to maintain resulting in it being more up-to-date and it would also be a bit faster. Unfortunately there is no such direct back-pressure in the open source community and developers usually don't have a long term view. Thank you for insulting our intelligence. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
On Tue, 3 Sep 2002, Garrett Wollman wrote: On Tue, 3 Sep 2002 09:31:52 -0700 (PDT), Julian Elischer [EMAIL PROTECTED] said: As long as I can set things up so that a chroot to an environment full of 2.2.6 binaries will still work, then I can still support sites with embedded 2.2.6 based things.. Others may find this a requirement too. I think more people probably care about this: /usr/local/lib/netscape/communicator-4.7.us.bin: FreeBSD/i386 compact demand paged dynamically linked executable Isn't this too old and security-holed to use? It stopped being packaged a few releases ago. 4.5R has mainly: /usr/local/lib/netscape-linux/communicator-linux-4.79.bin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped and mozilla. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
On Tue, 3 Sep 2002, Bakul Shah wrote:
Where exactly does GCC fit into the mix, making this impossible?
They compile Lisp (etc) to a C file, which they compile (with gcc) to
^^^
actually with as(1), because gcc is only generates assembler file,
which is then translated into the object file by assembler (as).
Assembler by itself is part of binutils, not a compiler suite.
Actually, it is part of old binutils, which is in FreeBSD's src tree but
hasn't been built by default for many years. Therefore it doesn't even
compile (except in my version of course):
%%%
Script started on Wed Sep 4 14:26:54 2002
ttyp0:bde@besplex:/tmp cvs -Q co as
ttyp0:bde@besplex:/tmp cd as
ttyp0:bde@besplex:/tmp/as make
Warning: Object directory not changed from original /tmp/as
updating targ-cpu.h...
updating obj-format.h...
updating host.h...
updating targ-env.h...
cc -O -pipe -DNON_BROKEN_WORDS -DPIC -I/tmp/as -I/tmp/as -I/tmp/as/config -DOLD_GAS
-DSIGTY=void -Derror=as_fatal -DSUB_SEGMENT_ALIGN=4 -DFREEBSD_AOUT-c
/tmp/as/config/tc-i386.c
In file included from /tmp/as/as.h:78,
from /tmp/as/config/tc-i386.c:31:
/usr/include/stdio.h:324: syntax error before '(' token
*** Error code 1
Stop in /tmp/as.
ttyp0:bde@besplex:/tmp/as exit
Script done on Wed Sep 4 14:27:04 2002
%%%
This is because misimplemented compatibility cruft setbuffer() was finally
bitten by reality.
I suspect Richard Tobin was using the generally accepted
meaning for a compiler as one that translates a source
program into object code (machine language). In any case, it
is cc1 that generates an assembly file. gcc is just a driver
program that calls various subprograms.
I suspect that he is also using old binaries for as and ld. It
would be safer to use an old compiler driver with them too.
Richard's main point with which I totally agree is that
please do not take away the ability to generate and grok
a.out files *if at all possible*. A number of Lisp systems
as well as Scheme one use ld -A friends to do what he
described. In general, please do not break backward
compatibility.
But must we support building new versions of the a.out utilities
and keep all the infrastructure (man pages and objformat...) up
to date? We haven't been doing that properly since 3.0R. Some
of te infrastructure is still built by default, but parts must be
built manually (as, ld, gdb ...) or old versions must be copied
from somewhere. gdb is most problematic (if you need it) since
old gdb's don't work out with current kernels. You have to check
out gdb-mumble from FreeBSD-mumble and recompile.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: KDE broken on CURRENT (with gcc3.2)
On Tuesday 03 September 2002 06:16 pm, Alexander Kabaev wrote: On Wed, 4 Sep 2002 20:59:20 + Michael Johnson [EMAIL PROTECTED] wrote: I am experiencing this behavior as well (can't compile kde3 with gcc 3.2.1 or 3.1). However, with Alexander Kabaev's gcc 3.2 patch to cp-lang.c, kdelibs compiles ok and I can get kdebase to install by doing The patch is not mine. I extracted it from GCC FSF CVS repository. I have the exact same problem (even with fam-2.6.9). Can you post that patch? Beech To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KDE broken on CURRENT (with gcc3.2)
I have the exact same problem (even with fam-2.6.9). Can you post that patch? There was an error with FAM and GCC 3.1 discussed here: http://oss.sgi.com/projects/fam/archive/msg00452.html If this is the problem you are seeing, try removing the const modifier from Scheduler.h in the FAM sources. If anyone can suggest why this is a FAM bug (rather than a GCC bug), I might be able to make the required changes in FAM. Hope this helps -- MICHAEL WARDLE SGI Desktop and Sysadmin Software Adacel Technologies Limited To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: aout support broken in gcc3
Bruce Evans wrote: Isn't this too old and security-holed to use? It stopped being packaged a few releases ago. 4.5R has mainly: /usr/local/lib/netscape-linux/communicator-linux-4.79.bin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped and mozilla. I personally use the FreeBSD native Netscape. I dislike loading the Linux emulator, for security reasons. Mozilla, Galeon, and other browsers claim to be better, but often fail to provide features that have been in Netscape for forever. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
