Re: [panic] panic during probe with a gcc 3.1 kernel
According to Steve Kargl: > I reported this earlier today. I had > hint.acpi.0.disable="1" > in /boot/loader.conf to disable ACPI. > If I comment out this hint, the system > boots, but I end up with the following in dmesg. Right, but if I want to be able to suspend / resume my laptop, I *need* to use APM and not ACPI. So I'm fscked up... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perl scripts that need rewriting - Progress!
> Hi, > > > On Thu, 09 May 2002 20:33:22 +0100 > > Mark Murray <[EMAIL PROTECTED]> said: > > mark> /usr/sbin/scriptdump > > This script is from KAME. It seems that NetBSD doesn't install it. > Is someone actually using it? If okay, I'll change to don't install > it. That sounds good to me! Go right ahead! :) M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn #text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
> On Sat, May 11, 2002 at 10:33:03AM -0700, David O'Brien wrote: > > I'll look this patch over carefully, but at first glance it all seems > > like stylistic changes. Does it fix a bug, or you just don't like how I > > did things? > > The changes are mostly _not_ stylistic like .ORDER with one argument > not making any sense. The reason of this patch is as before -- to > avoid redefining system Yacc building rules. The changes also fix > the -j buildworld breakage in gnu/usr.bin/cc/cc1plus: Maybe they are "cleaner" to you -- but the YACC rules for GCC are rather complicated and what I use is much more direct. You way requires me to remember the 3-4 different ways the YACC _implicit_ rules can affect the build. I feel that for every except you (and maybe BDE) the explicit rules are clearer and more straight forward. I do not see anything wrong with redefining system implicit YACC rules. You have repeatedly hounded me for quite a while about GCC. Since so much of my blood and sweat are not acceptable to you, I encourage you to become the GCC maintainer and do everything to your heart's desire. People are really making me regret that I sweated over GCC 3 to bring it into our tree for all of our architectures and to get many serious bugs fixed in the FSF CVS repository. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
On Sun, May 12, 2002 at 04:43:33AM -0700, David O'Brien wrote: > > On Sat, May 11, 2002 at 10:33:03AM -0700, David O'Brien wrote: > > > I'll look this patch over carefully, but at first glance it all seems > > > like stylistic changes. Does it fix a bug, or you just don't like how I > > > did things? > > > > The changes are mostly _not_ stylistic like .ORDER with one argument > > not making any sense. The reason of this patch is as before -- to > > avoid redefining system Yacc building rules. The changes also fix > > the -j buildworld breakage in gnu/usr.bin/cc/cc1plus: > > Maybe they are "cleaner" to you -- but the YACC rules for GCC are rather > complicated and what I use is much more direct. You way requires me to > remember the 3-4 different ways the YACC _implicit_ rules can affect the > build. I feel that for every except you (and maybe BDE) the explicit > rules are clearer and more straight forward. I do not see anything wrong > with redefining system implicit YACC rules. > They are not wrong, they are just redundant for most of the part. My changes tell how to build FreeBSD versions of YACC input (.y) files, and how to build FreeBSD versions of YACC output (.c and .h) files. This is only different from your version by letting sys.mk rules run yacc(1), in one well defined way. These changes also resemble those that were before your WIP_GCC31 merge, and for which you already agreed by committing them. Not to say they fix a real bug in the -j case and fix CLEANFILES. > You have repeatedly hounded me for quite a while about GCC. Since so > much of my blood and sweat are not acceptable to you, I encourage you to > become the GCC maintainer and do everything to your heart's desire. > Sorry I was working on cross-platform building issues in the past that also needed some changes in GCC and Binutils. Sorry I sent you too many patches which fixed bugs or added features. Sorry you can't hold an exclusive lock on the whole FreeBSD. Is this really your sight at things? I'm amazed. What you call "hounding" would better be classified as a pure technical feedback including patches and asking related questions, and maintainer is excepted to deal with this load, either accepting patches or rejecting them (giving valid technical reasons). If you aren't capable of accepting useful "critics" (in the form of patches and answering questions), I think you should seriously reconsider whether you really want to continue be a MAINTAINER. (I say "critics" because that's how you probably take what I call "feedback".) > People are really making me regret that I sweated over GCC 3 to bring it > into our tree for all of our architectures and to get many serious bugs > fixed in the FSF CVS repository. > What reward do you need for this? So that nobody reviews your commits, or looks to anything you are maintaining? You want the "god mode" in FreeBSD? Sorry but I'm affraid this is not possible, or FreeBSD should be renamed to ObrienBSD. GCC and Binutils are essential part of FreeBSD, sitting in its heart, and many other folks including me work on related issues, and apparently look to the work you're doing. From my first days in the project, I took it as a joint effort thing, in fact that's one of the reasons I agreed to become a committer, but behavior like you are demonstrating doesn't fold into this. What you don't seem to realize is that people like me and BDE _don't_ blame you but are just trying to help you do the work done. It's a real pita you see the things in a different light. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg38234/pgp0.pgp Description: PGP signature
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 >/tmp/des/obj/alpha/.amd_mnt/freefall/host/d/home/des/tinderbox/src/alpha/usr/include -- >>> stage 4: building libraries -- ===> cpp0 ... Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/lib/csu. *** Error code 1 Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src. *** Error code 1 Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src. *** Error code 1 Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src. *** Error code 1 Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Review requested for newly added manual page devinfo(8)
Hello, As per the request of rwatson; and a courtesy which I would like to fulfil. I would be very greatful if you could take a look at the newly added manual page, available at: src/usr.sbin/devinfo/devinfo.8 It was added on Sunday May/12 by Robert Watson. Thank you, Regards. -- Hiten Pandya -- <[EMAIL PROTECTED]> P.S. CC'ed to rwatson@ __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Problems with ssh connections and Pam on today's current.
With this morning's build I have somehow lost ssh. I get the following error: May 12 10:11:03 worldinternet sshd[24224]: in openpam_load_module(): no pam_nologin.so found May 12 10:11:03 worldinternet sshd[24224]: fatal: PAM initialisation failed[1]: failed to load module May 12 10:27:32 worldinternet sshd[24674]: in openpam_load_module(): no pam_nologin.so found May 12 10:27:32 worldinternet sshd[24674]: fatal: PAM initialisation failed[1]: failed to load module It was so strange that I opened a port for telnet as a test and it works fine and the same pam modules are found. Have I done something wrong? I'm going back to look at the changes and see if I can catch what happened. Thanks for any suggestions. ed - http://insourcery.com - Mergence of Business and Technology a "Griffin Plaza Partners, LLC" Company To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildworld broken in gcc
cc -O -pipe -march=athlon -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/usr/src/i386/usr\" -I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -DHAVE_CONFIG_H -DTARGET_NAME=\"i386-undermydesk-freebsd\" -DIN_GCC -D__FBSDID=__RCSID -c /usr/src/contrib/gcc/final.c -o final.o /usr/src/contrib/gcc/final.c: In function `final_scan_insn': /usr/src/contrib/gcc/final.c:2019: syntax error before "else" *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cc_int. *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc. *** Error code 1 Sources were updated via cvsup at 9:56 PDT on 12 May 02. I believe the above is a side effect of other problems in the build, because /usr/src/contrib/gcc/final.c was last updated 2 days ago and it compiled fine yesterday. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
David O'Brien wrote: > People are really making me regret that I sweated over GCC 3 to bring it > into our tree for all of our architectures and to get many serious bugs > fixed in the FSF CVS repository. Really? It must be in private email... from what I've seen, everything went incredibly smoothly -- moreso than could be reasonably expected. The only think I personally saw that was anywhere close to a real problem was the 96 byte boot bloat, which I think can be resolved with explicit aligns/#pragma pack(1), and disabling one of the speed vs. space optimizations (the instruction pipelining). The mailing lists have been, as far as I could tell, blissfully silent on the subject. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Special fx with disklabel(8)?
Hello, I have a -CURRENT from May 5th. I recently bought a new 40 gig IDE disk and proceeded to install it. I went for "compatible" (as opposed to "dangerously dedicated") mode. I first used fdisk to initialize the slice table and create a FreeBSD slice that would take in the whole disk. After that, I proceeded to disklabel the slice thus created. This used to work just fine with a commandline like this: disklabel -B -w -r /dev/ad1s1 auto But now, although the kernel complaints about the disk not having a disklabel stopped, I could not edit the label I supposedly just created, with the command: disklabel -e /dev/ad1s1 After checking with fdisk, it turned out that the slice I created there (which was the first "partition" in DOS parlance) got deleted, and replaced by a very small (something like 24 megs) slice listed as the fourth primary. In addition, although up till then the kernel detected the disk's size properly on bootup, it got confused and guessed it was bigger than in reality. I deleted and started over, again, fdisk went fine, the slice got created, I could see it with fdisk, it spanned the whole disk, but after the disklabel we were back to square one. When doing it for the third time, I, for the heck of it, tried "disklabel -e" right after the "fdisk -Bi". And, to my great surprise, a disklabel *was* found on the slice, and it was even mostly correct, save for the fact that now it seemed to stick to the erroneous values for c/h/s and size that it snatched out of thin air previously. (Note: The bad values are not necessarily a bug. The BIOS has no opinion on the disk because it is too big for it. When it tries to detect it, the machine just hangs. So, it is set to "None" in the BIOS setup, which allows the system to boot, but obviously the BIOS hints are not there. Obviously, this is not the only disk in the system, and not even the system disk:-) I am aware of disklabel changes recently, the question is: Was this some sort of expected, or are these special fx only fata morgana on my machine, or...? In other words, has the recommended way of installing a disk in "compatible" mode into the system changed? Is fdisk somehow supposed to create a disklabel? And, is disklabel expected to mess with the fdisk tabales? (when it is used on a slice, not the whole disk) Any and all hardware details available if needed. Have a nice weekend! -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Special fx with disklabel(8)?
DOS partition tables use a 24b C/H/S value. With 512B sectors, this means they are incapable of representing more than 8G of disk space. To support a 32b sector offset, you have to go to LBA mode. This isn't really supported by any BIOS that still respects the C/H/S offsets, since they will override. What probably happened is that you had an overflow that wrapped you back to the start of the disk. The general answer on this is: use "dangerously dedicated mode for very large disks". It's possible to work around this, but it's really a pain, and you have to know what you are doing. Chapter 5 of the PReP specification has an excellent tutorial on LBA addressing and DOS partition tables (much better than any Intel related information I have seen to date), if you want to fix this problem, rather than just ignoring it. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Special fx with disklabel(8)?
In message <[EMAIL PROTECTED]>, Terry Lambert writes: >DOS partition tables use a 24b C/H/S value. With 512B sectors, this >means they are incapable of representing more than 8G of disk space. Ahh, I love these time-warp emails from Terry. [*] This is the way the world looked circa 1990. I doubt any normal person has any MBR records which hasn't valid contents in the 32 bit sector count fields which have been part of the MBR record from at least 1994, and probably earlier. Please do not follow Terrys advice, unless and until you have independent confirmation that his 10 year old knowledge is still current. Poul-Henning [*] Not! > >To support a 32b sector offset, you have to go to LBA mode. This >isn't really supported by any BIOS that still respects the C/H/S >offsets, since they will override. > >What probably happened is that you had an overflow that wrapped >you back to the start of the disk. > >The general answer on this is: use "dangerously dedicated mode for >very large disks". > >It's possible to work around this, but it's really a pain, and you >have to know what you are doing. Chapter 5 of the PReP specification >has an excellent tutorial on LBA addressing and DOS partition tables >(much better than any Intel related information I have seen to date), >if you want to fix this problem, rather than just ignoring it. > >-- Terry > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Special fx with disklabel(8)?
Poul-Henning Kamp wrote: > Please do not follow Terrys advice, unless and until you have > independent confirmation that his 10 year old knowledge is still > current. Poul: "I will say that advice is bad, but I will not provide advice of my own, because it might be bad, too, and open me to the same type of attack I like to make on others. It's just so much easier to criticize someone than it is to help solve a problem and risk being attacked by someone else like me". -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Special fx with disklabel(8)?
In message <[EMAIL PROTECTED]>, Terry Lambert writes: >Poul-Henning Kamp wrote: >> Please do not follow Terrys advice, unless and until you have >> independent confirmation that his 10 year old knowledge is still >> current. > >Poul: "I will say that advice is bad, but I will not provide advice > of my own, because it might be bad, too, and open me to the > same type of attack I like to make on others. It's just so > much easier to criticize someone than it is to help solve a > problem and risk being attacked by someone else like me". Terry: "I would appreciate if you would ensure that your knowledge is up to date before you mislead people with it." -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
compilation failure (in the kernel SCSI code)
Hello, the import of GCC3.1 seems to reveal old bugs : (while cross-compiling a new kernel atfer cross-compiling a new -Current world under a fresh -Stable) (the %b flag is not recognized in the printf()s of scsi_low.c) %- cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I/files2/SrcCurrent/src/sys -I/files2/SrcCurrent/src/sys/dev -I/files2/SrcCurrent/src/sys/contrib/dev/acpica -I/files2/SrcCurrent/src/sys/contrib/ipfilter -I/files2/SrcCurrent/src/sys/../include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -mpreferred-stack-boundary=2 -ffreestanding -Werror /files2/SrcCurrent/src/sys/cam/scsi/scsi_low.c cc1: warnings being treated as errors /files2/SrcCurrent/src/sys/cam/scsi/scsi_low.c: In function `scsi_low_calcf_show': /files2/SrcCurrent/src/sys/cam/scsi/scsi_low.c:4661: warning: unknown conversion type character `b' in format /files2/SrcCurrent/src/sys/cam/scsi/scsi_low.c:4661: warning: too many arguments for format /files2/SrcCurrent/src/sys/cam/scsi/scsi_low.c: In function `scsi_low_print': /files2/SrcCurrent/src/sys/cam/scsi/scsi_low.c:4896: warning: unknown conversion type character `b' in format /files2/SrcCurrent/src/sys/cam/scsi/scsi_low.c:4896: warning: too many arguments for format /files2/SrcCurrent/src/sys/cam/scsi/scsi_low.c:4916: warning: unknown conversion type character `b' in format /files2/SrcCurrent/src/sys/cam/scsi/scsi_low.c:4916: warning: too many arguments for format /files2/SrcCurrent/src/sys/cam/scsi/scsi_low.c:4929: warning: unknown conversion type character `b' in format /files2/SrcCurrent/src/sys/cam/scsi/scsi_low.c:4929: warning: too many arguments for format *** Error code 1 Stop in /files2/obj/files2/SrcCurrent/src/sys/multi-Cur. *** Error code 1 Stop in /files2/SrcCurrent/src. *** Error code 1 Stop in /files2/SrcCurrent/src. portable# pwd %- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Special fx with disklabel(8)?
Hello everybody, OK, just in order to clarify before things get out of hand.:-) There is no immediate problem, the drive in question has been installed and works fine. (using it this instant). As for the BIOS part, the mobo could probably use an upgrade, because the BIOS is still from spring of 1998. Award BIOS-en from around that date had a problem that became known, as I learned through research, as the "65536 cyl", or "32GB barrier." The behaviour of the BIOS is very much like it. And yes, this is an Award PnP v4.51PG on a Shuttle Spacewalker HOT-637/P (Intel 440LX chipset. Yes, old:-) I was more curious than anything else: Since I disabled the drive in the BIOS, it was entirely up to FreeBSD to decide what to do. The boot process detected it with 79408/16/63, which is OK. The disklabel however, somehow contained a larger number than the disk's capacity and got the C value wrong. Of course, this was easily fixed with "disklabel -e". Indeed, an overflow somewhere might have caused the symptoms. This definitely did not happen on this system, under an earlier -CURRENT and with a then-new 15 gig disk. And no, I do not think 40 gig drives count as "very large" these days. I am not sure what would have happened, if the BIOS support had been correct to begin with. In fact, I did not even expect that the drive would be found and probed correctly under the present circumstances, in other words, FreeBSD caused a pleasant surprise. I just got a bit worried, since 80 gig disks are quickly becoming commonplace in modern PCs, and I was hoping that dd mode would not be *the* way to use them under FreeBSD:-). And Terry and Poul-Henning, please stop fighting, I am not going to do anything to the system wrt this just now:-) -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal
Gang, I occasionally get tcsh coredumps (signal 6). I mostly ignored it, but today I decided to track it down for once. This is the backtrace: (gdb) bt #0 0x808e4a3 in access () #1 0x80ba9fa in abort () at /usr/src/lib/libc/../libc/stdlib/abort.c:78 #2 0x80b97a9 in wrtwarning (p=0x80ef54e "in free():") at /usr/src/lib/libc/../libc/stdlib/malloc.c:314 #3 0x80b97c8 in wrtwarning (p=0x80ef54e "in free():") at /usr/src/lib/libc/../libc/stdlib/malloc.c:315 #4 0x80ba5aa in malloc (size=1644) at /usr/src/lib/libc/../libc/stdlib/malloc.c:1093 #5 0x8079163 in smalloc (n=1644) at /usr/src/bin/csh/../../contrib/tcsh/tc.alloc.c:505 #6 0x80757d8 in ReBufferDisplay () at /usr/src/bin/csh/../../contrib/tcsh/ed.screen.c:506 #7 0x8077cf9 in ChangeSize (lins=24, cols=80) at /usr/src/bin/csh/../../contrib/tcsh/ed.screen.c:1742 #8 0x8071542 in check_window_size (force=0) at /usr/src/bin/csh/../../contrib/tcsh/ed.init.c:128 #9 0x8071564 in window_change (snum=28) at /usr/src/bin/csh/../../contrib/tcsh/ed.init.c:148 #10 #11 0x80baa8f in memcpy () #12 0x80ba6c9 in free (ptr=0x814f600) at /usr/src/lib/libc/../libc/stdlib/malloc.c:1125 #13 0x8079287 in sfree (p=0x814f600) at /usr/src/bin/csh/../../contrib/tcsh/tc.alloc.c:586 #14 0x805c2ca in blkfree (av0=0x814f600) at /usr/src/bin/csh/../../contrib/tcsh/sh.misc.c:169 #15 0x8057600 in backeval (cp=0x8150900, literal=0) at /usr/src/bin/csh/../../contrib/tcsh/sh.glob.c:842 #16 0x80574e8 in dobackp (cp=0x8147060, literal=0) at /usr/src/bin/csh/../../contrib/tcsh/sh.glob.c:784 #17 0x8056aa1 in globexpand (v=0x814ac54) at /usr/src/bin/csh/../../contrib/tcsh/sh.glob.c:386 #18 0x8057171 in globall (v=0x814ac50) at /usr/src/bin/csh/../../contrib/tcsh/sh.glob.c:632 #19 0x80622c1 in set1 (var=0x814acf0, vec=0x814ac50, head=0x8130fc4, flags=2) at /usr/src/bin/csh/../../contrib/tcsh/sh.set.c:616 #20 0x806227a in set (var=0x814acf0, val=0x8147060, flags=2) at /usr/src/bin/csh/../../contrib/tcsh/sh.set.c:601 #21 0x8061a41 in doset (v=0x814f200, c=0x814cce0) at /usr/src/bin/csh/../../contrib/tcsh/sh.set.c:292 #22 0x8053428 in func (t=0x814cce0, bp=0x80f4a44) at /usr/src/bin/csh/../../contrib/tcsh/sh.func.c:149 #23 0x80608d7 in execute (t=0x814cce0, wanttty=634, pipein=0x0, pipeout=0x0) at /usr/src/bin/csh/../../contrib/tcsh/sh.sem.c:657 #24 0x8060b15 in execute (t=0x814ccc0, wanttty=634, pipein=0x0, pipeout=0x0) at /usr/src/bin/csh/../../contrib/tcsh/sh.sem.c:734 #25 0x804a847 in process (catch=0) at /usr/src/bin/csh/../../contrib/tcsh/sh.c:2125 #26 0x804a0f9 in srcunit (unit=3, onlyown=1, hflg=0, av=0x0) at /usr/src/bin/csh/../../contrib/tcsh/sh.c:1661 #27 0x8049cce in srcfile (f=0x814b700 "USER", onlyown=1, flag=0, av=0x0) at /usr/src/bin/csh/../../contrib/tcsh/sh.c:1468 #28 0x8049c70 in srccat (cp=0x814ca00, dp=0x80f64a4) at /usr/src/bin/csh/../../contrib/tcsh/sh.c:1441 #29 0x8049973 in main (argc=0, argv=0xbfbffaa4) at /usr/src/bin/csh/../../contrib/tcsh/sh.c:1301 Apparently what's happening is that tcsh get's interrupted while in free() and the signal handler itself calls malloc(). Note that this typically happens when I open a new GNOME terminal. I guess the grand question is: is this a genuine bug or just a nasty side effect of our malloc options? -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal
That one's easy to diagnose: You change your windowsize while tcsh happened to be in free(3) (frame #12). tcsh gets the SIGWINSZ (sp?) signal, and tries to allocate a buffer, probably a new line-edit buffer, calls malloc(3) (fram #4) and malloc abort(3)'s the program. It is not legal to recursively call malloc/free/realloc, and therefore you should either protect all calls to malloc/free/realloc by blocking signals or better: not call them in signal handlers. The correct solution is probably to set a flag in the signal handler and resize the buffer before the next line is read. Poul-Henning In message <[EMAIL PROTECTED]>, Marcel Moolenaar writ es: >Gang, > >I occasionally get tcsh coredumps (signal 6). I mostly ignored it, >but today I decided to track it down for once. This is the backtrace: > >(gdb) bt >#0 0x808e4a3 in access () >#1 0x80ba9fa in abort () at /usr/src/lib/libc/../libc/stdlib/abort.c:78 >#2 0x80b97a9 in wrtwarning (p=0x80ef54e "in free():") at >/usr/src/lib/libc/../libc/stdlib/malloc.c:314 >#3 0x80b97c8 in wrtwarning (p=0x80ef54e "in free():") at >/usr/src/lib/libc/../libc/stdlib/malloc.c:315 >#4 0x80ba5aa in malloc (size=1644) at /usr/src/lib/libc/../libc/stdlib/malloc.c:1093 >#5 0x8079163 in smalloc (n=1644) at >/usr/src/bin/csh/../../contrib/tcsh/tc.alloc.c:505 >#6 0x80757d8 in ReBufferDisplay () at >/usr/src/bin/csh/../../contrib/tcsh/ed.screen.c:506 >#7 0x8077cf9 in ChangeSize (lins=24, cols=80) at >/usr/src/bin/csh/../../contrib/tcsh/ed.screen.c:1742 >#8 0x8071542 in check_window_size (force=0) at >/usr/src/bin/csh/../../contrib/tcsh/ed.init.c:128 >#9 0x8071564 in window_change (snum=28) at >/usr/src/bin/csh/../../contrib/tcsh/ed.init.c:148 >#10 >#11 0x80baa8f in memcpy () >#12 0x80ba6c9 in free (ptr=0x814f600) at >/usr/src/lib/libc/../libc/stdlib/malloc.c:1125 >#13 0x8079287 in sfree (p=0x814f600) at >/usr/src/bin/csh/../../contrib/tcsh/tc.alloc.c:586 >#14 0x805c2ca in blkfree (av0=0x814f600) at >/usr/src/bin/csh/../../contrib/tcsh/sh.misc.c:169 >#15 0x8057600 in backeval (cp=0x8150900, literal=0) at >/usr/src/bin/csh/../../contrib/tcsh/sh.glob.c:842 >#16 0x80574e8 in dobackp (cp=0x8147060, literal=0) at >/usr/src/bin/csh/../../contrib/tcsh/sh.glob.c:784 >#17 0x8056aa1 in globexpand (v=0x814ac54) at >/usr/src/bin/csh/../../contrib/tcsh/sh.glob.c:386 >#18 0x8057171 in globall (v=0x814ac50) at >/usr/src/bin/csh/../../contrib/tcsh/sh.glob.c:632 >#19 0x80622c1 in set1 (var=0x814acf0, vec=0x814ac50, head=0x8130fc4, flags=2) at >/usr/src/bin/csh/../../contrib/tcsh/sh.set.c:616 >#20 0x806227a in set (var=0x814acf0, val=0x8147060, flags=2) at >/usr/src/bin/csh/../../contrib/tcsh/sh.set.c:601 >#21 0x8061a41 in doset (v=0x814f200, c=0x814cce0) at >/usr/src/bin/csh/../../contrib/tcsh/sh.set.c:292 >#22 0x8053428 in func (t=0x814cce0, bp=0x80f4a44) at >/usr/src/bin/csh/../../contrib/tcsh/sh.func.c:149 >#23 0x80608d7 in execute (t=0x814cce0, wanttty=634, pipein=0x0, pipeout=0x0) at >/usr/src/bin/csh/../../contrib/tcsh/sh.sem.c:657 >#24 0x8060b15 in execute (t=0x814ccc0, wanttty=634, pipein=0x0, pipeout=0x0) at >/usr/src/bin/csh/../../contrib/tcsh/sh.sem.c:734 >#25 0x804a847 in process (catch=0) at /usr/src/bin/csh/../../contrib/tcsh/sh.c:2125 >#26 0x804a0f9 in srcunit (unit=3, onlyown=1, hflg=0, av=0x0) at >/usr/src/bin/csh/../../contrib/tcsh/sh.c:1661 >#27 0x8049cce in srcfile (f=0x814b700 "USER", onlyown=1, flag=0, av=0x0) at >/usr/src/bin/csh/../../contrib/tcsh/sh.c:1468 >#28 0x8049c70 in srccat (cp=0x814ca00, dp=0x80f64a4) at >/usr/src/bin/csh/../../contrib/tcsh/sh.c:1441 >#29 0x8049973 in main (argc=0, argv=0xbfbffaa4) at >/usr/src/bin/csh/../../contrib/tcsh/sh.c:1301 > >Apparently what's happening is that tcsh get's interrupted while >in free() and the signal handler itself calls malloc(). Note that >this typically happens when I open a new GNOME terminal. > >I guess the grand question is: is this a genuine bug or just a nasty >side effect of our malloc options? > >-- > Marcel MoolenaarUSPA: A-39004 [EMAIL PROTECTED] > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld broken in gcc
On Sun, May 12, 2002 at 10:32:33AM -0700, Steve Kargl wrote: > cc -O -pipe -march=athlon -DIN_GCC -DHAVE_CONFIG_H >-DPREFIX=\"/usr/obj/usr/src/i386/usr\" >-I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools >-I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools >-I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc >-I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -DHAVE_CONFIG_H >-DTARGET_NAME=\"i386-undermydesk-freebsd\" -DIN_GCC -D__FBSDID=__RCSID -c >/usr/src/contrib/gcc/final.c -o final.o > /usr/src/contrib/gcc/final.c: In function `final_scan_insn': > /usr/src/contrib/gcc/final.c:2019: syntax error before "else" > *** Error code 1 This is fixed. Please cvsup. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal
< said: > The correct solution is probably to set a flag in the signal handler > and resize the buffer before the next line is read. Or, somewhat less optimally, to block SIGWINCH (and any other signals with similar handler behavior) around calls to malloc and free. This is still not *correct*, mind you, but will make the condition less likely. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [panic] USB related panic
On Sat, May 11, 2002 at 02:00:38PM +0200, Ollivier Robert wrote:
>
> FreeBSD sidhe.freenix.org FreeBSD 5.0-CURRENT #6: Thu May 9 17:14:15 CEST 2002
> [EMAIL PROTECTED]:/local/src/src/sys/i386/compile/SIDHE i386
>
> Sony VAIO Z600TEK, current just before gcc 3.1.
>
> Having tested the usb subsystem a few weeks ago (it hung during resume), I
> decided to try after the latest fixes from Joe. kldload usb; kldload ums
> and I plugged my optical mouse (see below the messages).
>
> Then I suspend/resume the machine. This time it didn't hung (thanks Joe!)
> but the mouse wasn't functionning. Killing and restarting usbd gave
> nothing. I then decided to kill moused: instant panic...
>
> Joe, any idea?
>
Both uhci and ohci have suspend/resume code in them that's not
activated yet (it didn't port clean, and I've not put the time into
sorting it out yet). I guess that stack frame #13 to #19 are usb code
and that you're running it from a module so the debugger doesn't have
access to the symbols. If you get a moment perhaps you could track
down where in the usb code the panic occured. I compile the usb driver
into the kernel to get around the symbol problem.
Joe
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0xdeadc0de
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xce8fd9f7
> stack pointer = 0x10:0xce7f6ac8
> frame pointer = 0x10:0xce7f6adc
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 536 (moused)
> trap number = 12
> panic: page fault
> syncing disks... panic: bremfree: bp 0xc7496f60 not locked
> Uptime: 30m26s
> pfs_vncache_unload(): 1 entries remaining
> Dumping 255 MB
> ata0: resetting devices .. done
> 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
> ---
> #0 doadump () at ../../../kern/kern_shutdown.c:213
> 213 dumping++;
> #0 doadump () at ../../../kern/kern_shutdown.c:213
> #1 0xc017e53d in boot (howto=260) at ../../../kern/kern_shutdown.c:346
> #2 0xc017e6d5 in panic (fmt=0xc026fd99 "bremfree: bp %p not locked")
> at ../../../kern/kern_shutdown.c:490
> #3 0xc01aa811 in bremfree (bp=0xc7496f60) at ../../../kern/vfs_bio.c:619
> #4 0xc01abf47 in vfs_bio_awrite (bp=0xc7496f60)
> at ../../../kern/vfs_bio.c:1593
> #5 0xc020c118 in ffs_fsync (ap=0xce7f6980) at
> ../../../ufs/ffs/ffs_vnops.c:219
> #6 0xc020a93e in ffs_sync (mp=0xcda98000, waitfor=2, cred=0xc7373f00,
> td=0xc0298cc0) at vnode_if.h:441
> #7 0xc01b8c71 in sync (td=0xc0298cc0, uap=0x0)
> at ../../../kern/vfs_syscalls.c:1224
> #8 0xc017e1fb in boot (howto=256) at ../../../kern/kern_shutdown.c:254
> #9 0xc017e6d5 in panic (fmt=0xc0289b3e "%s")
> at ../../../kern/kern_shutdown.c:490
> #10 0xc024c1e2 in trap_fatal (frame=0xce7f6a88, eva=3735929054)
> at ../../../i386/i386/trap.c:826
> #11 0xc024bf2d in trap_pfault (frame=0xce7f6a88, usermode=0, eva=3735929054)
> at ../../../i386/i386/trap.c:740
> #12 0xc024bb73 in trap (frame={tf_fs = -1070858216, tf_es = -830537712,
> tf_ds = 16, tf_edi = -34, tf_esi = -833817856, tf_ebp = -830510372,
> tf_isp = -830510412, tf_ebx = -830098048, tf_edx = 0, tf_ecx = 4,
> tf_eax = -559038242, tf_trapno = 12, tf_err = 0, tf_eip = -829433353,
> tf_cs = 8, tf_eflags = 66182, tf_esp = -833817856, tf_ss = -833298432})
> at ../../../i386/i386/trap.c:426
> #13 0xce8fd9f7 in ?? ()
> #14 0xce900969 in ?? ()
> #15 0xce900b34 in ?? ()
> #16 0xce8fd9c5 in ?? ()
> #17 0xce8fd6f0 in ?? ()
> #18 0xce7bca11 in ?? ()
> #19 0xce7bca8e in ?? ()
> #20 0xc015c201 in spec_close (ap=0xce7f6b90)
> at ../../../fs/specfs/spec_vnops.c:617
> #21 0xc015b839 in spec_vnoperate (ap=0xce7f6b90)
> at ../../../fs/specfs/spec_vnops.c:121
> #22 0xc01beb20 in vn_close (vp=0xce50, flags=7, cred=0xce85b380,
> td=0xce7f2728) at vnode_if.h:183
> #23 0xc01bf726 in vn_closefile (fp=0xce39ad98, td=0xce7f2728)
> at ../../../kern/vfs_vnops.c:798
> #24 0xc0169c8a in fdrop_locked (fp=0xce39ad98, td=0xce7f2728)
> at ../../../sys/file.h:225
> #25 0xc016946f in fdrop (fp=0xce39ad98, td=0xce7f2728)
> at ../../../kern/kern_descrip.c:1635
> #26 0xc016943c in closef (fp=0xce39ad98, td=0xce7f2728)
> at ../../../kern/kern_descrip.c:1621
> #27 0xc0168e2d in fdfree (td=0xce7f2728) at
> ../../../kern/kern_descrip.c:1375
> #28 0xc016d8bf in exit1 (td=0xce7f2728, rv=0) at
> ../../../kern/kern_exit.c:201
> #29 0xc016d642 in sys_exit (td=0xce7f2728, uap=0xce7f6d20)
> at ../../../kern/kern_exit.c:109
> #30 0xc024c46b in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
> tf_edi = 0, tf_esi = -1, tf_ebp = -1077938896, tf_isp = -830509708,
> tf_ebx = 672189240, tf_edx = 672188640, tf_ecx = -1077938384,
> tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = 671786
Re: does the order of .a files matter?
On Fri, May 10, 2002 at 01:35:56PM -0700, Terry Lambert wrote: > Mikhail Teterin wrote: > > = For my information: Why didn't you take John De Bowsky's advice to: > > = > > = ld $objlist `lorder $liblist | tsort -q` > > > > I tried that before I asked on the mailing list the first time. It > > did reduce the number of the undefined symbols, but not to zero. > > It's possible that the symbols are truly undefined (e.g. "stat64"), > but I think that is unlikely. > > Here is what I think: > > Your proximal problem is that your libraries are badly organized, and > therefore certain object files in them are not being pulled into the > linking process, because your order of operation on the objects is not > in dependency order, because of the improper organization. A challenge: Linkers normally pull in everything they can from archive libraries and do not require that object files in archive libraries be ordered in dependency order, nor do they require archive libraries to contain object files multiple times to break circular dependencies. They do this by iterating over the archive library until no new binding is possible (whether it's iterating over the index or over the whole archive). If you think that providing bits on the link line in dependency order is a natural way of linking and the "proper" way of doing it, how do you explain our improper use of putting object files in lexical order in libraries and how do you resolve the contradiction that from a build point of view the lexical order is the proper way of building and we only get away with that because the linker doesn't require object files in archive libraries to be in dependency order (or we manually correct the situation by duplication)? Also, to me it looks like a gross inconsistency that can be easily solved by having the linker remember symbols it has seen (and where) even though they are not unresolved at the time the symbols are seen. How does reordering or restructuring source code solely to make the linker happy be in anyway better than simply make the linker less dumb (be it optional)? I don't intend to start a discussion, just contemplation when I say: The reason linkers behave the way they do does not necessarily have to be a good one according to current standards. I've often wondered about what makes the current behaviour good and have never found a reason better than "it's easier for the linker". This however can easily be rejected as unimportant, because tools are supposed to make it easier for the user. To me the behaviour of linkers is therefore mostly hysterical and I personally would not use it as an argument to distinguish good source organisation from bad... > Most linkers don't do what you want, which is make up for programmer > incompetence by doing an automatic topological sort on all symbol Which programmers do you mean: the programmers writing linkers or...? :-) -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal
On Sun, May 12, 2002 at 11:27:42PM +0200, Poul-Henning Kamp wrote: > > It is not legal to recursively call malloc/free/realloc, and therefore > you should either protect all calls to malloc/free/realloc by blocking > signals or better: not call them in signal handlers. Ok, thanks. I guess we have a genuine tcsh(1) bug here. Who's maintaining tcsh? Can he/she suggest what to do or otherwise take it from here? -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal
At 3:20 PM -0700 5/12/02, Marcel Moolenaar wrote: >On Sun, May 12, 2002 at 11:27:42PM +0200, Poul-Henning Kamp wrote: >> >> It is not legal to recursively call malloc/free/realloc, and therefore >> you should either protect all calls to malloc/free/realloc by blocking >> signals or better: not call them in signal handlers. > >Ok, thanks. I guess we have a genuine tcsh(1) bug here. > >Who's maintaining tcsh? Can he/she suggest what to do or otherwise >take it from here? I've been maintaining tcsh. Can you file a PR and assign it to me? I'll follow up with the tcsh owner to resolve the problem. Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal
On Sun, May 12, 2002 at 03:32:49PM -0700, Mark Peek wrote: > > I've been maintaining tcsh. Can you file a PR and assign it to me? > I'll follow up with the tcsh owner to resolve the problem. PR: bin/38006. Backtrace and and libc hack to easily reproduce the condition included. Thanks, -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
i386 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 /tmp/des/obj/i386/d/home/des/tinderbox/src/i386/usr/include -- >>> stage 4: building libraries -- ===> kerberosIV/lib/libkdb ... /d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: passing arg 1 of `des_pcbc_encrypt' from incompatible pointer type /d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: passing arg 2 of `des_pcbc_encrypt' from incompatible pointer type /d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c: In function `kdb_encrypt_key': /d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: passing arg 1 of `des_pcbc_encrypt' from incompatible pointer type /d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: passing arg 2 of `des_pcbc_encrypt' from incompatible pointer type ===> kerberosIV/lib/libkrb ===> kerberosIV/lib/libtelnet cc1: warnings being treated as errors /d/home/des/tinderbox/src/crypto/telnet/libtelnet/kerberos.c: In function `kerberos4_cksum': /d/home/des/tinderbox/src/crypto/telnet/libtelnet/kerberos.c:496: warning: unreachable code at beginning of switch statement *** Error code 1 Stop in /d/home/des/tinderbox/src/kerberosIV/lib/libtelnet. *** Error code 1 Stop in /d/home/des/tinderbox/src/kerberosIV/lib. *** Error code 1 Stop in /d/home/des/tinderbox/src. *** Error code 1 Stop in /d/home/des/tinderbox/src. *** Error code 1 Stop in /d/home/des/tinderbox/src. *** Error code 1 Stop in /d/home/des/tinderbox/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Special fx with disklabel(8)?
Poul-Henning Kamp wrote: > >> Please do not follow Terrys advice, unless and until you have > >> independent confirmation that his 10 year old knowledge is still > >> current. > > > >Poul: "I will say that advice is bad, but I will not provide advice > > of my own, because it might be bad, too, and open me to the > > same type of attack I like to make on others. It's just so > > much easier to criticize someone than it is to help solve a > > problem and risk being attacked by someone else like me". > > Terry: "I would appreciate if you would ensure that your knowledge > is up to date before you mislead people with it." Poul: "Of course, *my* knowledge is up to date because *I'm* Poul; but I'll be damned if I'll share it, because then I can't beat people over the head for not having it, and beating people over the head is ever so much more fun, isn't it? Meanwhile, I'm still not going to answer the original poster's question...". -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Special fx with disklabel(8)?
On Sun, May 12, 2002 at 10:19:45PM -0700, Terry Lambert wrote: > Poul-Henning Kamp wrote: > > >> Please do not follow Terrys advice, unless and until you have > > >> independent confirmation that his 10 year old knowledge is still > > >> current. > > > > > >Poul: "I will say that advice is bad, but I will not provide advice > > > of my own, because it might be bad, too, and open me to the > > > same type of attack I like to make on others. It's just so > > > much easier to criticize someone than it is to help solve a > > > problem and risk being attacked by someone else like me". > > > > Terry: "I would appreciate if you would ensure that your knowledge > > is up to date before you mislead people with it." > > Poul: "Of course, *my* knowledge is up to date because *I'm* Poul; but >I'll be damned if I'll share it, because then I can't beat people >over the head for not having it, and beating people over the head >is ever so much more fun, isn't it? Meanwhile, I'm still not >going to answer the original poster's question...". Gentlemen.. does this discussion on a public list serve any useful purpose? -- | / o / /_ _ FreeBSD core team secretary |/|/ / / /( (_) Bulte [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: does the order of .a files matter?
Marcel Moolenaar wrote: > > Here is what I think: > > > > Your proximal problem is that your libraries are badly organized, and > > therefore certain object files in them are not being pulled into the > > linking process, because your order of operation on the objects is not > > in dependency order, because of the improper organization. > > A challenge: > > Linkers normally pull in everything they can from archive libraries Actually, they don't. They only pull in onjects that define symbols that are undefined at the time the library is encountered, in order, on the linker line. Anyone who doesn't believe this needs to write an X11 application that uses Xt, Xext, and some widget toolkit, and then play with library order other than "-lX11 -lXt -lXext". > and do not require that object files in archive libraries be ordered > in dependency order, nor do they require archive libraries to contain > object files multiple times to break circular dependencies. They do > this by iterating over the archive library until no new binding is > possible (whether it's iterating over the index or over the whole > archive). Actually, they do this by looking at the library symbol index, which is either created automatically by the ar, or, on BSD based systems, added by the program "ranlib". > If you think that providing bits on the link line in dependency order > is a natural way of linking and the "proper" way of doing it, how do > you explain our improper use of putting object files in lexical order > in libraries and how do you resolve the contradiction that from a build > point of view the lexical order is the proper way of building and we > only get away with that because the linker doesn't require object > files in archive libraries to be in dependency order (or we manually > correct the situation by duplication)? I explain the lexical ordering by way of the following commands when exiting the Makefile in "vi" in command mode: !!ls *.c J[...] ISRCS= 8-). > Also, to me it looks like a gross inconsistency that can be easily > solved by having the linker remember symbols it has seen (and where) > even though they are not unresolved at the time the symbols are seen. "info ld" This is not historical UNIX "ld" behaviour, and it is not default GNU "ld" behaviour. > How does reordering or restructuring source code solely to make the > linker happy be in anyway better than simply make the linker less > dumb (be it optional)? When you are using a library as a library, rather than as a silly workaround to command line length limitations, you only want to pull in the object files from the archive which are actually used. By ordering the source code properly, less code gets pulled in when you are not actually using every function within a library. Linking fewer object files into an executable makes the executable smaller. Smaller executables are better than larger executables from a putatively "smarter" linker (personally, I measure linker intelligence as inversely proportional to the resulting executable size, relative to the idealized executable size). Also, putting related code adjacently results in the code fitting within the peephole. This permits the cimplier's optimizer to do things that it would otherwise be unable to do. Optimized executables are better than those that aren't. So organizing functions into the correct object modules, and the object modules into correct libraries, rather than choosing the organization at random, is important, if you care about code size and/or optimizer efficiency. > I don't intend to start a discussion, just contemplation when I say: > > The reason linkers behave the way they do does not necessarily have > to be a good one according to current standards. I've often wondered > about what makes the current behaviour good and have never found a > reason better than "it's easier for the linker". This however can > easily be rejected as unimportant, because tools are supposed to make > it easier for the user. To me the behaviour of linkers is therefore > mostly hysterical and I personally would not use it as an argument > to distinguish good source organisation from bad... The most common excuse I'm aware of is "To get faster compile times when benchmarked against other compilers". On slow enough, or emulated, hardware, though, it's a legitimate complaint that linking speed becomes a developement bottleneck. > > Most linkers don't do what you want, which is make up for programmer > > incompetence by doing an automatic topological sort on all symbol > > Which programmers do you mean: the programmers writing linkers or...? > > :-) I had a big gripe, complete with examples involving famous names, ready to go. But I will replace it with a much smaller response: "A craftsman must know his tools". -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Keywords: pre-GCC3 tcsh coredump free/malloc reentrancy signal
Marcel Moolenaar wrote: > On Sun, May 12, 2002 at 11:27:42PM +0200, Poul-Henning Kamp wrote: > > It is not legal to recursively call malloc/free/realloc, and therefore > > you should either protect all calls to malloc/free/realloc by blocking > > signals or better: not call them in signal handlers. > > Ok, thanks. I guess we have a genuine tcsh(1) bug here. > > Who's maintaining tcsh? Can he/she suggest what to do or otherwise > take it from here? The Single UNIX Specification Standard and POSIX both explicitly state that it is not safe to call memory management functions from signal handlers. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current Build Error
I'm getting the following on today's -current: cc1: warnings being treated as errors /usr/src/sys/dev/ata/atapi-fd.c: In function `afd_describe': /usr/src/sys/dev/ata/atapi-fd.c:191: warning: too many arguments for format *** Error code 1 Stop in /usr/obj/usr/src/sys/NOVA. *** Error code 1 I built with -DNO_WERROR, but it didn't seem to matter. Also, cvsup was done just prior, and an hour later. Any suggestions? Beech -- --- Beech Rintoul - SysAdmin - [EMAIL PROTECTED] /"\ ASCII Ribbon Campaign | Sinbad Network Communications \ / - NO HTML/RTF in e-mail | 3101 Penland Parkway #K-38 X - NO Word docs in e-mail | Anchorage, AK 99508-1957 / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
