Re: Fixing -pthreads (Re: ports and -current)
On Wed, Sep 24, 2003 at 11:51:53AM +0200, Sheldon Hearn wrote:
> Okay, so what are we supposed to do to ports that are now broken because
> -pthread doesn't exist (e.g. devel/pwlib)?
-pthread is back in current. It just had a little holiday. It's back,
refreshed, eager and willing to do the deed. 8-)
> Is there a simple rule we should follow when trying to fix ports, or do
> we have to think now?
Someone has to think and make a decision. Is simplicity (the -pthread switch)
reason enough to support one thread library by default?
> At the moment, I'm just patching configure files
> to use ${PTHREAD_LIBS} instead of -pthread, and pushing PTHREAD_LIBS
> into the ports' CONFIGURE_ENV.
I don't think that CONFIGURE_ENV should be modified in each port's makefile
to cope with PTHREAD_LIBS. It's supposed to be a ports-wide thing, so it
belongs in bsd.port.mk.
--
John Birrell
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Initial list of ports that fail due to -pthread
On Wed, Sep 24, 2003 at 08:01:35AM +0200, Stijn Hoop wrote: > - fix all ports to respect PTHREAD_LIBS _ON THE LINKING STAGE_ (so no > global search & replace, for it shouldn't be used in compile command lines) > - keep '-pthread' as a compiler option, which maps to a NOOP for compiling > and '-lpthread' (aka libkse) for linking > - set PTHREAD_LIBS to the default value of -pthread > - allow PTHREAD_LIBS to be set to something other, e.g. '-lthr', in > /etc/make.conf (or the make command line) > > What is the problem with this approach? You get both a 'standard' -pthread > knob, _and_ the ability to select your threads library using ports. > Third party apps that use -pthread will work. The only case in which some > work has to be done by a FreeBSD user is when they want to link a non-ported > third-party app with a library other than libpthread (libkse). I think you are probably right. We need to remember that third party apps fit best in ports if they work out of the box without patches and twiddles. We probably should only rely on PTHREAD_LIBS for the non-standard cases where people want to be clever. -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Initial list of ports that fail due to -pthread
On Wed, Sep 24, 2003 at 01:49:50AM -0400, Daniel Eischen wrote: > It would be nice to be able to support all our thread > libraries, but I grow weary. I grow weary yesterday. -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Initial list of ports that fail due to -pthread
On Tue, Sep 23, 2003 at 07:33:43PM -0700, Kris Kennaway wrote:
> Won't these ports still need to be fixed to look at
> PTHREAD_{LIBS,CFLAGS} though, since the correct values for 4.x and 5.x
> will still be different?
Not if -pthread remains. Internally gcc would link to a different
library, but most ports won't see that.
--
John Birrell
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Initial list of ports that fail due to -pthread
On Tue, Sep 23, 2003 at 07:18:21PM -0700, Kris Kennaway wrote: > Here is a partial list of the ports that need to be taught to respect > PTHREAD_LIBS and PTHREAD_CFLAGS, from the latest 5.x package build (I > just grepped for the "-pthread is deprecated" error message). None of > these were fixed by ports/57047. It is likely that there are many > more that also need to be fixed - either they fail in other ways, or > are hidden by depending on another port that currently fails. I had a go at fixing some of the ones listed on your status page. I started with the ones that had the greatest number of dependencies. The thing I'm not sure about is whether there is consensus that the -pthread argument should be removed from GCC. I've supported Dan's approach because I understand the background. I think there have been a few too many "don't do that" emails. I'm tempted to suggest that -pthread be kept and set to the default thread library (which I think should be libpthread aka libkse). If FreeBSD really wants to have an alternate thread library (libthr), then add another argument to toggle that. I know that'll make things confusing, but having more than one thread library is more confusing than a change to -pthread. -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Sun, Sep 21, 2003 at 01:25:09AM -0700, Doug Barton wrote: > I am a little confused about one thing though. What is going to > happen to third party apps that use -pthread that aren't compiled > through the ports? They need to replace -pthread with their thread library of choice (e.g. -lc_r or -lpthread). -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
On Sun, Sep 21, 2003 at 01:07:15AM -0400, Daniel Eischen wrote: > But you seem to thing -pthread == NOOP unbreaks ports ;-) Warner might, but Kris doesn't. Kris is asking for the -pthread option to be restored to let -current users breath easy while the task of updating the ports goes on. Then he's happy for it to become a noop. I susect theat this puts much of the work on a few people rather than many. I hope it doesn't require a volley of emails to each port maintainer to resolve each one. People have jumped off buildings for less than that! -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On Sat, Sep 20, 2003 at 07:24:07PM -0700, Kris Kennaway wrote: > 3) You, John Birrell, and whoever else is interested in fixing these > ports can work on them at your own pace without disrupting life for > the rest of the users. Once they're all fixed, we can turn the error > back on or make it a NOP or do whatever else is decided to be > appropriate. OK, so what's the commit procedure going to be? This could generate an awful lot of little PRs. Scot posted a patch for bsd.port.mk. Is that going to be committed? That's needed. Are you prepared to unlock the ports tree and allow a blanket commit auth for commits that only change patch-configure? That should catch most of the simple cases. -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
On Sat, Sep 20, 2003 at 08:06:25PM -0600, M. Warner Losh wrote: > But it was completely removed. That sounds like the consensus wasn't > followed. Why was it then removed? It got discussed a bit more after the removal. That was the time when the GCC people got involved. The discussions where on FreeBSD public lists. > So we change -pthread to mean "link in the default threading package, > with whatever magic is necessary for that package" rather than "link > in libc_r instead of libc". A better way is to just link to the thread package you want. Keep knowledge of thread libraries outside GCC. There really is nothing simpler that adding -lc_r or -lpthread or -lmyownthreadlib. No magic required. > Then why was it completely removed? Dan removed it because it wasn't needed and nobody said anything otherwise. > At the very least, we should put it back as a noop. The timing on > this really sucks because it breaks the ports tree for an extended > period of time. While the fixes are simple, they haven't been made > yet. The fact that the tree is frozen makes it seem like a really bad > time to make the change. Yes, I think it should go back as a noop (mostly to satisfy the GCC people though). It sucks that the 4.9 pre-release instability has been so severe. It bit me so much I ended up using current instead. Major functionality changes to things like VM shouldn't be made so late in a branch. It is a point *NINE* release after all. Unfreeze the ports tree then! I'm not a ports committer, but I'm willing to help out fixing the problems on -current if that would help. Lets go forward, not back. -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
On Sat, Sep 20, 2003 at 07:05:33PM -0600, M. Warner Losh wrote: > Why does -pthread necessarily force selection of one specific > threading library? All it means is that it is that the program uses > posix threads, at least traditionally. How FreeBSD causes that to > happen is an interesting implementation detail for some, but irrelvant > for most ports. Couldn't -pthread be made to give the user the > default threading package, and for those that matter a more specific > one can be specified? This subject *has* been discussed both within FreeBSD and with the GCC maintainers. I think that the consensus from those who chose to participate in that discussion was that -pthread would be a noop on FreeBSD. > It is insane to have FreeBSD be different than all other systems for > this trivial reason. Why fix everthing in the world when allowing > -pthread to be a noop would solve the problem? Seems like we're being > overly picky for no real gain. I guess I just don't understand. Having -pthread as a noop doesn't fix the ports breakage. For years ports have worked on the basis that libc_r was linked to get user-space threads *instead* of libc. This was the result of certain people in the FreeBSD developer community not wanting thread stubs in libc. Since libc was linked by default (unless -nostdlib was specified), it was necessary to have gcc know to use libc_r instead. That is why the -pthread argument was added. FWIW, Linux and the other BSDs didn't have a -pthread argument back then. Now that libc has thread stubs in libc (in current), there is no longer any need to have gcc know about any of the thread libraries. That's a good thing IMO. The FSF wants GCC to have a -pthread argument on all platforms and they are happy to have it as a noop. I doubt that there would ever be a good time to make this change. The fact that 4.9 has been delayed is making the problem seem worse because people can't commit fixes to the tree. While 4.9 is delayed (due to the PAE instability which never should have been allowed), the ports tree should be unlocked. The fixes are simple. Make them and move on. -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
fxp hangs reseting to a stable state
This is the first time I've tried to run -current on this little board. Up-to-date RELENG_4 kernels run fine. The probe message (port & memory) values are the same. On -current, the kernel gets up to the point in the fxp code where it is supposedly doing a "reset to a stable state" and then it hangs. I have set the kernel option BREAK_TO_DEBUGGER, but I can't get it to drop to DDB. The fxp driver reports that it is using memory space register mapping, so I guess that there is something different about the memory access in -current compared to RELENG_4. The question is what? I assume it's not a bios setup problem since RELENG_4 works fine. The kernels are net booted (using etherboot) over the very device that -current hangs on. Weird. Any hints on what is going on? -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: config(8) KERNEL setting
On Thu, Sep 04, 2003 at 12:31:33PM +0200, Dag-Erling Sm?rgrav wrote:
> I have
>
> Index: kern.pre.mk
> ===
> RCS file: /home/ncvs/src/sys/conf/kern.pre.mk,v
> retrieving revision 1.34
> diff -u -r1.34 kern.pre.mk
> --- kern.pre.mk 22 Aug 2003 15:41:44 - 1.34
> +++ kern.pre.mk 29 Aug 2003 21:06:02 -
> @@ -9,7 +9,8 @@
> # Can be overridden by makeoptions or /etc/make.conf
> KERNEL_KO?=kernel
> KERNEL?= kernel
> -KODIR?=/boot/${KERNEL}
> +KODIR?=/boot/${KERN_IDENT}
> +BOOTKODIR?=/boot/${KERNEL}
>
> M= ${MACHINE_ARCH}
>
>
> and in /boot/loader.conf:
>
> kernel="dwp_smp"
> #kernel="dwp_up"
My kernel is intended for netbooting and the loader isn't needed.
It seems what I really should be using is:
makeoptions KERNEL_KO=foo
That gives me what I need.
--
John Birrell
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
config(8) KERNEL setting
In a RELENG_4 kernel build, I'm accustomed to setting 'config foo' in
a kernel configuration file and ending up with a kernel called 'foo'.
In current, kern.pre.mk contains:
KERNEL_KO?= kernel
KERNEL?=kernel
KODIR?= /boot/${KERNEL}
however kern.post.mk only uses KERNEL_KO, so even though config(8) has
set KERNEL for me, that name only gets used for the boot directory.
There doesn't seem to be any way of getting KERNEL_KO set from the
kernel config file.
It would make more sense to me if kern.pre.mk contained this:
KERNEL?=kernel
KERNEL_KO?= ${KERNEL}
KODIR?= /boot/${KERNEL}
Comments?
--
John Birrell
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question related to FreeBSD Serial Console...
On Mon, Sep 01, 2003 at 05:29:09PM -0600, Scott Long wrote: > At one time I was working on patches to the loader to make the console > speed configurable. At the time, at least, I didn't see any evidence > that the settings were stored in the boot0 block, but maybe I was wrong. AFAIK, the boot0 block uses bios int 0x16 to get a key-press and bios int 0x10 to display a character, so in a situation where you *want* a serial console, the F1 etc stuff can't be used unless the bios supports console re-direction. And you have to live with whatever baud rate the bios sets. Once you get to boot2, then the serial console can work if set in /boot.config. It would be nice to have a boot.config setting for the baud rate. I have a board here that allows bios re-direction to either the first or second serial port at a fixed baud rate of 38400. I have to build boot2 with BOOT_COMCONSOLE_SPEED=38400, and then the kernel with CONSPEED=38400 to get all the ducks in a row. But it would be even nicer if both boot2 and the kernel would just work with whatever baud rate the bios set. -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Heads up: checking in change to ata-card.c
On Mon, Aug 04, 2003 at 10:45:39PM -0700, Stephen Casner wrote:
> I tried what I thought might be the equivalent patch (eliminating an
> else clause), but it did not solve the problem. In 4.8-RELEASE I
> sometimes get a system hang and sometimes not, but even when it does
> not hang, I just get "Device not configured" when I try to mount
> /dev/acd0c. The output I get is:
>
> /kernel: pccard: card inserted, slot 0
> pccardd[49]: Card " "("NinjaATA-") [V1.0] [AP00 ] matched " " ("NinjaATA-")
> [(null)] [(null)]
> /kernel: ata2 at port 0x180-0x187,0x386 iomem 0xd4000-0xd4fff irq 9 slot 0 on
> pccard0
> pccardd[49]: ata2: NinjaATA inserted.
I saw similar behaviour with STABLE when trying to use a CompactFlash card
on a CPU board that didn't support the default range of I/O ports. This might
not be the case you have, but I saw output just like that quoted above. The
ata device gets reported, but there is no 'ad' device following it like there
normally is.
In my case the solution was to use the I/O port range hidden in the manufacturer's
notes on their web site. Once I set the port range in /etc/pccard.conf to
override the default, the CompactFlash card worked fine.
--
John Birrell
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Who is responsible for the install check goo in Makefile.inc1
On Wed, Jul 30, 2003 at 10:37:29AM +0300, Ruslan Ermilov wrote: > Sure, that would be a much better (and safer) approach. Could you > please send me your code as well, I'm interested in revieweing it. I'd just like to add something like this before Peter's check that runs sh: @OSRELDATE=`sysctl -n kern.osreldate`; \ if [ $$OSRELDATE -lt 500043 ]; then \ echo "The kernel you are running does not support the executables you are about to install!"; \ echo "You need to install a new kernel and reboot before doing an installworld."; \ echo "If you have already installed a new kernel, perhaps your loader configuration"; \ echo "needs to be updated to reflect the fact that kernels are now installed below"; \ echo "the /boot directory (not in the root directory."; \ exit 1; \ fi > P.S. Nice to see you're still in the FreeBSD business. :-) Actually I'm /only/ in the FreeBSD business. I've been concentrating on getting a FreeBSD based product ready for release. I'm at the second prototype stage and things are looking promising. The SCO vs IBM case is a reminder of why I chose *BSD in the first place. I'm a bit embarrassed that I haven't contributed more in the last year or so. At some point I'll need to upgrade the product to 5.X, so I need to start working in that direction. While I'm getting a current machine up and running I'd like to sort out the uprade issues while I'm still prepared to trash the install. Peter's grim reaper email is a regular reminder. I think I'm up to number 11. Hehehehe. -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Who is responsible for the install check goo in Makefile.inc1
On Wed, Jul 30, 2003 at 10:24:42AM +0300, Ruslan Ermilov wrote: > I'm regularly upgrading 4.0-RELEASE to 5.x-CURRENT to check that > the upgrade path wasn't broken, and this check comes very handy. > I wouldn't object though if it was done using kern.osreldate. > > I'd happily test any patches in this direction for you, John. Thanks. Since Peter made the change, I'd like to wait for him to comment on the code I sent him that would avoid the core dump. I think that running sh as a final check is valid, but I'd like to see a 'probable' case checked first and an message printed accordingly before making the core dump as a last resort (in favour of shooting the whole foot off - one toe is better than the whole foot!). -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4.8->Current & Depreciated files
On Wed, Jul 30, 2003 at 04:44:54PM +0930, Benjamin Close wrote: > I'm about to upgrade from FreeBSD 4.8 to Current (following the > instructions in UPDATING) and was just wondering if mergemaster removes > depreciated files between the two versions. Ie: /etc/rc.sendmail I believe > is now depreciated to one of the rcNG scripts. Does merge master handle > the deleting of this file or is there some other utility? I've just been through this. The instructions would have you run mergemaster -p before doing an installworld. For me, that only tried to update /etc/passwd and /etc/group which already had the sendmail users and groups so there was nothing to update. After doing the installworld, mergemaster knows about the rc.d change and running mergemaster (without -p) did not cause any grief. For me, the update was most error prone around the stage where the new kernel had been installed and a reboot was asked for (see src/Makefile). The old loader installation still thought that the kernel was in the root directory and loaded it instead of the 5-current version. >From the boot prompt you need to unload /kernel and load /boot/kernel/kernel manually before doing the installworld. Then things will go according to plan. If you don't do that, you'll get a core dump from sh when the installcheck is performed by src/Makefile.inc1 and you won't be sure what has gone wrong if you didn't notice that the new kernel you supposedly installed wasn't actually run. -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 8MB install
On Wed, Jun 25, 2003 at 10:15:19PM -0700, Terry Lambert wrote: > There *are* other ways to install than booting a CDROM; they are > just more labor intensive, and require FreeBSD running on a more > poswerful machine to set up the install for the other machine. True. Anyone who wants to install on a small machine should consider using a network boot first. Build on a faster machine, then user etherboot on the target machine to check it out. Sure it'll be slow, but all you have to do once the machine is netbooted is fdisk, label the disk, newfs it and copy over the stuff you need. Then reboot. If it doesn't work, netboot again and have another go. -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Weak symbols in libc_r broken?
On Sun, Mar 12, 2000 at 11:07:40PM -0800, David O'Brien wrote: > On Mon, Mar 13, 2000 at 02:52:02PM +1100, John Birrell wrote: > > Is it just me, or are the weak symbols in libc_r confusing the linker? > > Not just you. Jason and Mike Smith brought this to my attention on > Friday. I found that if one takes a fresh -CURRENT and then: > > cd /usr/src/lib/libc_r > cvs -q up -D 1/27/2000 > make all install > > the susp.c code from the A&W Ptheads Programming book > (http://www.aw.com/cseng/titles/0-201-63392-2/code/) would then work with > compiled with "-static -pthread". I don't think it is the linker's fault. To me it makes no sense to have a weak symbol and a strong symbol of the same name in the same library. I deleted the weak definitions in the _THREAD_SAFE PRSYSCALL in lib/libc/i386/SYS.h and the problem goes away. I don't understand why Jason needed to add them in the first place. -- John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/ [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weak symbols in libc_r broken?
On Mon, Mar 13, 2000 at 03:16:39PM +1100, Peter Jeremy wrote: > Out of interest, why does nanosleep appear in libc_r.a as a weak > symbol version of _thread_sys_nanosleep at all? I would have thought > this was unnecessary (and based on my experiments, undesirable). I don't think it is necessary. It got caught up in the cancellation changes that Jason made. > > >Is there someone with a recent -current system who has time to try > >this out? > > I have -current from 9th March and get the same results you do. > Looking at last night's buildworld results, there doesn't appear to > be any change in the symbols in libc_r.a and when I try manually > performing the link with the ld in /usr/obj/..., I still get the > same result. > > >... then libc_r is broken. > > This is a particularly bad time to discover what appears to be a > fairly serious bug in the threaded libraries and/or linker. > > I just tried fiddling with the order in which uthread_nanosleep.o and > nanosleep.o appear in libc_r.a. It seems that the linker always picks > the first definition of the symbol found after the first reference to > the symbol - whether it is weak or not. Since nanosleep.o appears > before uthread_nanosleep.o, the non thread-safe version will be > picked. > > I suspect the only solution is to dispose of the weak symbols - > re-ordering the object file isn't an option given the requirement > for the non-weak symbol to always appear between the reference and > the weak symbol. I agree. Thanks for helping out. -- John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/ [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Weak symbols in libc_r broken?
Is it just me, or are the weak symbols in libc_r confusing the linker?
When I link the following program with "gcc -v -g -static -pthread"
#include
#include
int main (int argc, char *argv[])
{
struct timespec t1;
struct timespec t2;
t1.tv_sec = 5;
t1.tv_nsec = 0;
nanosleep(&t1,&t2);
printf("Remaining time %ld.%09ld\n",(long) t2.tv_sec, (long) t2.tv_nsec);
return(0);
}
the linker gives me the weak symbol version which refers to
_thread_sys_nanosleep (i.e. the syscall), instead of the nanosleep
function in libc_r.
Is there someone with a recent -current system who has time to try
this out? Link the program and use gdb to disassemble the nanosleep
function. If you get:
(gdb) disassemble nanosleep
Dump of assembler code for function nanosleep:
0x804821c : leal 0xf0,%eax
0x8048222 :int$0x80
0x8048224 :jb 0x8048214
0x8048226 : ret
0x8048227 : nop
End of assembler dump.
... then libc_r is broken.
TIA.
--
John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/
[EMAIL PROTECTED] [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Weak symbols (Was: World breakage in libc_r?)
On Fri, Oct 15, 1999 at 08:09:57PM +0200, Wilko Bulte wrote: > Sheer curiosity and most likely a somewhat dim question: > > what the h* is a weak versus a strong symbol? A weak symbol is like an alias for another (strong) symbol. The linker will link to strong symbols first, then, for any unresolved references, it will try to resolve against the weak symbols before going on to the next library. Weak symbols are a good way to hide things in order to stop polluting the name space. But they can cause problems too. Our use of weak symbols in libc is incomplete. Although syscalls like read() have _read() as the strong symbol and read() as the weak one, we continue to call read() in other areas of libc. This means that a user can create their own read() function and they won't get a clash when they link against libc, but other functions in libc that really want to call the _read() syscall will call the user's read() function instead. That's broken. We really need to change libc in the way that NetBSD did with their namespace.h stuff. This ensures that the internals of libc call the hidden names, not the weakly exported ones. -- John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World breakage in libc_r?
On Thu, Oct 14, 1999 at 05:35:05PM -0400, Daniel Eischen wrote: > One of the things on my wish list is a libpthread that can be linked > with libc. So the way to accomplish this is to have null hooks with > weak symbols in libc, and provide the same (non-null) functions in > libpthread but with strong symbols? Weak symbols don't work too well _between_ libraries. If libc is linked before libpthread, any unresolved references when libc is searched will use the weak symbols from there, regardless of the fact that a strong symbol exists in libpthread. If libc is linked after libpthread, then you can have libc internal references to things that should been resolved to things in libpthread, but end up using the weak symbols in libc because that is all there is left. 8-( Not a simple problem to solve. The current tools don't help at all. A second library pass to resolve weak symbols would have been better. It's too late for that now, though, since you can change the semantics on the shared loader. -- John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: World breakage in libc_r?
On Thu, Oct 14, 1999 at 02:06:40PM -0700, John Polstra wrote: > On a related topic, we should fix the Alpha to emit the weak alias > like the i386 does. That's for ANSI/ISO C compliance, so that if a > user defines his own version of read(), it won't affect the behavior > of, say, getc(). We need a lot more of this throughout the C library > for both target platforms. And we need to fix the calls inside there > to use the "_xxx" symbols rather than the "xxx" versions. When I put the weak symbol stuff in, it did work on the alpha. Must have got lost in the version upgrades. > > Don't ya just love people who say "we" need to do stuff? :-) "Don't ya just love tools people who say "we" need to do stuff to tools?" 8-) -- John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Still waiting for xl driver reports
On Sun, Oct 10, 1999 at 04:59:34PM -0400, Bill Paul wrote: > I need feedback from people so that I know it's safe to merge this > stuff into -stable, so let's hear it already. It's been several weeks > since I made the changes. Surely there are people running -current > with 3Com 3c90xB cards. > > To reiterate, this only concerns people with the following adapters: > > - 3c905B-TX 10/100 I installed 3.2-RELEASE and upgraded to 4.0-CURRENT on a new machine last week. The machine came with NT installed - it is far more useful running FreeBSD. 8-) I can't comment about the relative performance, because I have nothing to compare it against. It works fine for me. -- John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Built-in linker library search paths
On Sun, Aug 29, 1999 at 11:00:17AM -0700, David O'Brien wrote: > > I'd like to remove the search paths altogether, leaving the gcc > > LIB_SPEC and LD_LIBRARY_PATH environment variable to get the /right/ > > path all the time. > > Can you post a patch first? IIRC jdp wanted to be more "pure" with ld.so > finding shared libs. Many didn't like the more "pure" searching. I > really can't tell what the result of your proposed changes would be. I found my own objection 8-). I was proposing to simply remove the SEARCH_DIR() lines in the linker scripts on the assumption that gcc (and egcs) knows about /usr/lib. What I didn't check before sending the original email was that gcc actually passes -L/usr/lib to ld. It doesn't, despite the fact that gcc -print-search-dirs reports /usr/lib as a search directory. Even with -nostdlib, gcc still passes the built-in search paths to ld, except for /usr/lib. Yuck. The conclusion that I reached was that the gcc sources would need to be changed to pass -L/usr/lib to ld and that if I did this, we would have a build problem where ld would be built without the searching before the new gcc. I don't think Cygnus would want this sort of change, and I'm certain FreeBSD users don't want the chicken-an-egg build problem. I found this problem building cross tools. I've settled (for the time being) on leaving a single SEARCH_DIR() in the linker script for /usr/lib or the cross-build library path depending on which target I'm building for. I think I'm at the point where I have all the binutils stuff configured to be able to build i386, m68k, powerpc, mips and sparc (and alpha only on alpha) hosted on FreeBSD, targeted to LynxOS, VxWorks, RTEMS, WinNT, NetBSD, Linux, SunOS, ... I'm still trying to find a simple way to build gcc/egcs for each based on the way you build FreeBSD's host compiler. -- John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Built-in linker library search paths
Ever since we started using binutils with the move to elf we've been using linker scripts with library search paths. The genscripts.sh source from binutils is giving us at least one bogus path all the time, and the presence of a not-always-appropriate-path (/usr/lib) the rest of the time. I'd like to remove the search paths altogether, leaving the gcc LIB_SPEC and LD_LIBRARY_PATH environment variable to get the /right/ path all the time. Any objections? -- John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problem with vnconfig -s labels ...
On Sat, Aug 21, 1999 at 04:30:57PM +1000, Bruce Evans wrote: > >Hmmm, I know this is your code, but are you sure? 8-). My understanding of > >dkmodslice() and friends is that they manipulate dev_t entries, but don't > >actually initialise them. Since the subr_diskslice code takes a dev_t > > dkmodslice() once just manipulated bits in dev_t scalars. Now that dev_t > is a pointer, dkmodslice() has to create something for the pointer to > point to. That something needs to be fully initialised and not created > more than once. The initialisation is apparently incomplete. Multiple > creation is avoided by searching the list of previously created entries. I agree that something has to create something for the dev_t pointer to point to, but I thought that it would be the device code that would do that. I've only looked at this from the perspective of vn, since that is what is biting me 8-). -- John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problem with vnconfig -s labels ...
On Sat, Aug 21, 1999 at 07:30:46AM +0200, Poul-Henning Kamp wrote: > >but I'm still looking for the place > >where the dev1 entry is supposed to be initialised. > > In dkmodslice() (and friends). Hmmm, I know this is your code, but are you sure? 8-). My understanding of dkmodslice() and friends is that they manipulate dev_t entries, but don't actually initialise them. Since the subr_diskslice code takes a dev_t and goes off and accesses the raw partition entry, my guess is that vnopen() should check if the raw entry has been initialised, and if not do it, just like it does for the one you open. -- John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problem with vnconfig -s labels ...
On Sat, Aug 21, 1999 at 04:22:46AM +0200, Luigi Rizzo wrote: > Hi, > > > I've found panics are more likely to occur if the command pair is > > executed in a script vs. from the command line. This may suggest some > > sort of race is occurring. > > no idea... i have always managed to panic the system even running the > commands from the command line one at a time, so i don't think it is a > race. > > I think i also got the paninc trying a disklabel when the "vn" device > was not in the kernel, but this one i had no time to reproduce. The problem is that disklabel executes code in subr_diskslice.c which does: dev1 = dkmodslice(dkmodpart(dev, RAW_PART), slice); The 'dev' structure has s_drv1 set correctly, but the 'dev1' entry has s_drv1 NULL. When vnstrategy() is called using dev1, vn = bp->b_dev->s_drv1 is NULL when it shouldn't be. The first time vn is referenced... fall down go boom. In my code (a bit similar to what picobsd is doing), I can open /dev/vn0, ioctl(fd,VNIOCATTACH,...), ioctl(fd,VNIOCUSET,...) and close without a problem. Execing '/sbin/disklabel -Brw /dev/rvn0 blah' causes the machine to panic. I've patched vnstrategy() to fail gracefully if bp->b_dev->s_drv1 is NULL, but I'm still looking for the place where the dev1 entry is supposed to be initialised. -- John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bus error in isatty() from /usr/lib/libc.so.3
Thimble Smith wrote: > Hello. I have a reproducable problem which gdb says is ending up at > 0x2818d862 in isatty() from /usr/lib/libc.so.3. A full back trace is > below. If this is a problem in FreeBSD, I'm very glad to do any > experiments that might be helpful. If it's a problem somewhere else, > any pointers on what I might do next would be great. [...] > #1 0x2818db22 in isatty () from /usr/lib/libc.so.3 > #2 0x2818e1de in malloc () from /usr/lib/libc.so.3 > #3 0x28236e88 in _thread_fd_table_init () from /usr/lib/libc_r.so.4 > #4 0x28238056 in _thread_fd_lock_debug () from /usr/lib/libc_r.so.4 You are linking against both libc _and_ libc_r. "Don't do that!" -- John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Using float emulator on a system with FPU?
Alex Zepeda wrote: > On Mon, 12 Jul 1999, Brian F. Feldman wrote: > > > Why shouldn't we? Noone uses machines without FPUs anymore. What > > non-ancient CPU doesn't have an FPU? And we're talking about the i386 > > family here... Nonsense. Read this: <http://developer.intel.com/design/intarch/prodbref/27270903.htm> > I've noticed recently, more and more, Linux is moving into the embedded > market quite nicely, and being used on smaller and smaller systems. > FreeBSD OTOH has been focusing (albeit not too successfully) on the higher > end market. That's a matter of perspective. Remember that people can base a product on FreeBSD without being forced to give away their value-added sources. I have a solar powered i386 board here that consumes just 2W. It runs FreeBSD. There is a tiny bit of custom code to initialise the board and boot the kernel out of flash, but the kernel is standard FreeBSD. > With my recent addition of an 040 powered Mac that I plan to put NetBSD > on, this really irks me. I'd love to put some (read: a significant) > amount of time getting FreeBSD up and running on this, but there seems to > be a lot of resistance to using FreeBSD on smaller/older machines. It > almost seems like the requirement is Pentium III, Alpha or bust. I don't think that is true. You are commenting on what other people have chosen to put their time into. The only resistance I see is people actually doing the work. To get in-principle approval before doing a substantial amount of work, ask [EMAIL PROTECTED] My bet is they won't object. -- John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How to cross build
Warner Losh wrote:
> You'll need to do this for all binutils as well.
I already build binutils with multi-architecture support. On alpha,
I have "CROSS_TOOLS= i386 m68k" in my /etc/make.conf and at the
end of a make world I have one ld that knows all the formats. Only
gas is a special case, so I have "as" (the alpha ELF one), as_i386
(the cross ELF assembler) and as_m68k. At the moment the FreeBSD
build drops the extra two in /usr/libexec/elf, which is wrong for
egcs.
> That would preclude us from porting to an architecture named "ftpd" or
> any other program that is in /usr/libexec. I think you want to put a
> /arch/ before the ${TARGET}, if you go down this path...
Ah, yes, point taken.
> Also, I think that your notion of running
> make world INCLUDE_THESE_OTHER_TARGETS="mips m68k"
> and then building the world (somehow) with these cross tools differs
> from my world view. In my world view (which may be wrong, but was
> what I arrived at after many false starts down other paths), one would
> build the entire system with make buildworld. I do see the utility in
> being able to do it other ways. But it would require more than just
> programs to make it work.
You're concentrating on porting FreeBSD. I'm trying to improve my
cross-compilation environment for my third-party code. In particular,
I still use VxWorks targeted to m68k (and also alpha). I will get a
faster build if I do it on i386 rather than my slower Alpha OSF/1
machine.
To build VxWorks stuff cross compiled under OSF/1, I set:
GCC_EXEC_PREFIX=/usr/opt/VXW310/bin/gnu/lib/
CPU=MC68020
AR=ar68k
CC=cc68k
LD=ld68k
and include /usr/opt/VXW310/bin/gnu in PATH.
These are the names and paths that DEC and Wind River use for the
VxWorks product that DEC sells (or did before being absorbed into Compaq).
To cross build FreeBSD code one one architecture for another should
be no more difficult once the Makefiles have been massaged.
> I suspect that /usr/libexec/${TARGET} will prove to be too limited to
> work in practice, especially for an entire buildworld (although I can
> see how it could be made to work for kernel builds). I think we'd
> need to have a /usr/cross/${TARGET}-${TARGET_ARCH}/ tree where the
> libraries needed for linking, the include files that are specific to
> each port, etc live. Then one could just set one's path to have
> /usr/cross/${TARGET}-${TARGET_ARCH}/bin in your path and then make
> from there anything you'd like. That would also allow us to have as
> many different binaries as we need to build the world and we'd be
> decoupled from any hacks to make binutils work. While this approach
> would work well for kernel development, I don't see how it would work
> well for development where libc is linked in.
I was referring to TARGET=elf32-i386, for example. In a cross build mode,
setting DESTDIR would be required rather than optional, but that
path can't be in PATH because it contains only files in the target
format, not tools that run on the host.
> P.S. /usr/cross is what OpenBSD uses, but I'm not married to that
> name.
Does OpenBSD use /usr/cross for the location of the cross _tools_,
or as the root of the target specific DESTDIR? I guess it is for the
tools.
--
John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/
CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: How to cross build
Warner Losh wrote:
>
> OK. Per many requests from the community, I've committed my cross
> compilation changes.
Thanks.
> To build you just say
> make buildworld TARGET=hpcmips TARGET_ARCH=mipsel
> or
> make buildworld TARGET=m68k TARGET_ARCH=m68k
> Right now you must specify both TARGET and TARGET_ARCH. You will want
> to do this with a clean /usr/obj. Please send comments to me.
>
> The one time I tried it, I was unable to build alpha binaries on i386
> due to bugs in the gnu tools. That was before egcs, however.
> Building i386 binaries on the alpha may work, but I don't have access
> to my Alpha lately to try.
binutils on i386 won't build 64-bit stuff due to bit shift code that
wants to shift more than 32 bits. At runtime the code strikes asserts
due to BFD64 not being defined at compile time. The sources hint at
using "long long" if using gcc, but it appears to require some hacking.
There is a Cygnus doc for configuring gcc 2.8.1 as a cross compiler which
says that building 32-bit code on a 64-bit machine doesn't quite
work. egcs might work though.
> This is a work in progress. Since I've been using this on MIPS, whose
> kernel includes aren't yet complete enough for make world, I don't
> know if it will work completely or not. The goal is to have a
> buildworld complete and then do an installworld in the native
> environment, or with a DESTDIR= to put the files in, say, an NFS
> mounted root partition.
>
> I did try to make this work with by redefining BINFORMAT, but I found
> too many problems with doing this because cc1 isn't dependent on
> BINFORMAT. It was easier to build explicit cross tools to make this
> happen.
I was aiming to build a set of cross tools as (an optional) part of the
i386 build like binutils. When building the cross-compiler, defining
CROSS_COMPILE and setting the execution path will avoid the native
compiler. Then in the mk files, set CC etc to be the cross compiler
based on the TARGET definition. The current install directory for the
extra gas versions should change to be the execution path that egcs is
configured for. I agree that BINFORMAT is inadequate. Since ld can be
shared between target formats, I guess a link to the host ld is all
that is required.
We can't rely on the setting of MACHINE_ARCH to twiddle the different
egcs build because that is a host setting, not a target one. We need
to set aside different directories and build the egcs code as many times
as the targets we want (like we do for gas). I've been using
/usr/libexec/${TARGET} where TARGET is a name quite close to that which
binutils knows. Using the environment variable "TARGET" is a little
problematic for me because it is easily confused (at least by my
brain 8-) with .TARGET.
> I've been using the cross binaries for a variety of purposes, so I
> have good confidence in at least that part of the commit.
--
John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/
CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Fixing other people's code (was: world broken in vinum (PATCH))
Greg Lehey wrote: > > Well, you asked! > > And you answered :-) > > So where were you at 3 am this morning? In a land far, far, far away. Then I woke up. 8-) -- John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fixing other people's code (was: world broken in vinum (PATCH))
Greg Lehey wrote: > I personally think that, in such a case, you'd be justified to commit > it as a temporary measure. Due to the difference in time zones, this > has hit people while I've been asleep. That doesn't mean the commit > would stay, of course, but at least it would save people unnecessary > pain. Note, of course, that I have now committed the correct file, > which I had forgotten last night. > > What do you others think? I think you shouldn't sleep. Well, you asked! -- John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cdevsw changes broke world in vinum
Gary Palmer wrote: > John Birrell wrote in message ID > <199906020405.oaa05...@cimlogic.com.au>: > > If you were reading the commit messages, you would have noticed that > > phk said he mailed patches for vinum and i4b to the respective authors. > > i4b has since been fixed (AFAIK) and vinum is waiting for Greg to stop > > galavanting around China on his way to Usenix I doubt that he'll > > be able to do anything for a few weeks. Just be patient. > > If its on the order of weeks for this to get fixed, I think removing > the vinum module from the build process is in order ... its breaking > the snapshots by stopping make world/make release... I think it would be better to make phk's commits. That way vinum should keep working and be up-to-date for those people who would be hurt by using an incompatible module. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cdevsw changes broke world in vinum
Leif Neland wrote: > On Wed, 2 Jun 1999, John Birrell wrote: > > If you were reading the commit messages, you would have noticed that > > phk said he mailed patches for vinum and i4b to the respective authors. > > i4b has since been fixed (AFAIK) and vinum is waiting for Greg to stop > > galavanting around China on his way to Usenix I doubt that he'll > > be able to do anything for a few weeks. Just be patient. > > > I don't use vinum, but how do I turn it off in my config-file? You should just edit the parent Makefile (sys/modules/Makefile) and remove vinum if that's where the build barfs. [ IMHO this is one situation where phk should just go ahead and make the edit. ] -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: cdevsw changes broke world in vinum
Charles Anderson wrote: > On Tue, Jun 01, 1999 at 12:17:03PM +0200, Sheldon Hearn wrote: > > > > The offending line is: > > > > cdevsw[CDEV_MAJOR] = NULL; /* no cdevsw any more */ > > > > Should that be vinum_cdevsw? Or did I get unlucky and pull sources > > between commits? > > > > Ciao, > > Sheldon. > > I got the same error, I supped around 10, did a buildworld, look at the > results later in the afternoon, saw the error, did a make dirclean, re- > supped, and rebuilt, same error. So I say unless the commits were REAL > far apart, it wasn't between commits. If you were reading the commit messages, you would have noticed that phk said he mailed patches for vinum and i4b to the respective authors. i4b has since been fixed (AFAIK) and vinum is waiting for Greg to stop galavanting around China on his way to Usenix.... I doubt that he'll be able to do anything for a few weeks. Just be patient. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Debugging uthreads
Daniel Eischen wrote: > Why don't we make a libc_r_db and provide the necessary interfaces to > gdb from that instead of having gdb know about uthread internals? It would still mean that gdb would be linked to the uthread internals which may not match the version of libc_r that the 3rd party program was linked against. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Debugging uthreads
Doug Rabson wrote: > I think the only state which I need to know about is PS_DEAD. If we marked > dead threads in the public struct it might simplify things. You use PS_RUNNING too. We could just tie down those two as PS_DEAD = 0 and PS_RUNNING = 1. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Debugging uthreads
Doug Rabson wrote: > Ok, I'll see about updating my patch along these lines and I'll post up > another one in a day or two. One more thing... the states are subject to change, probably with new states being added. It is important to check that the state number is within the range that gdb was compiled against (the states probably should be in the common header) and if the state number is out of that range, just display the number. Then we just need to ensure we add new states at the end. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Debugging uthreads
Doug Rabson wrote: > That would work. I think I only need uniqueid, sig_saved, > saved_sigcontext, saved_jmpbuf, state and nxt. If those guys were lumped > up at the start of struct pthread (possibly in another struct so that gdb > doesn't need to know sizeof(struct pthread)) and marked appropriately then > the debugger interface would be quite stable. I'd be inclined to add the magic number too, because it gives a hint as to whether the structure refers to a valid thread. If the thread is destroyed, the magic number is trashed. I think it is worth adding a new header file defining such a structure. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Debugging uthreads
Doug Rabson wrote: > Other gdb thread debugging systems tend to export a set of variables from > the thread library which describe the important offsets in the thread > structure e.g. _debug_pthread_status_offset, _debug_pthread_foo_offset > etc. > > If you think there will be a real problem, I could do this I guess. Maybe we should just isolate the things that gdb is allowed to look at and document them as "cast in stone". -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Debugging uthreads
Doug Rabson wrote: > I didn't want to use the address since it might cause confusion if a > thread was freed and then the memory was re-allocated to create a new > thread. Good reason. > I thought about the versioning but I don't think it will be a problem in > practice since both uthread and gdb will generally be built by a single > 'make world'. But libc_r isn't linked into anything during a 'make world'. It is only linked to 3rd party applications. So, although libc_r and gdb are in sync at the end of a 'make world', any statically linked applications will be out-of-sync (if an internal change has been made to libc_r). I'm not sure there is an easy solution to this. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Debugging uthreads
Doug Rabson wrote: > I've put an initial version of my hack for debugging FreeBSD user threads > with gdb up on http://www.freebsd.org/~dfr/uthread.diff. Comments would be > appreciated. Is the uniqueid really necessary when the address of the thread structure is already unique within the process address space? After all, that's what the thread ID is (a pointer to the malloc'd memory). I have the feeling that there needs to be some way to discover if the version of gdb being used is compatible with the version of libc_r that the program is linked against. Otherwise we end up with a similar problem to the all too familiar "struct proc size mismatch". -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
ROOTDEVNAME changes break MFS_ROOT only kernels
Prior to the ROOTDEVNAME changes, I used to build embedded kernels with MFS_ROOT and MFS_ROOT_SIZE options, plus the config line as: config foo root on wd0 but _without_ any disk devices or disk controllers. The "root on wd0" on the config line was to satisfy the config(8) syntax, but was overriden by the use of MFS_ROOT AFAIK. After the ROOTDEVNAME changes, the kernel always tries to mount a root file system from a _device_ regardless of the MFS_ROOT option. Such a kernel will always panic with: "error 6: panic: cannot mount root (2)". FWIW, this is the kernel config file for an embedded kernel (called gizmo): # # GIZMO -- A little gizmo thingy. # machine "i386" cpu "I386_CPU" ident GENERIC maxusers2 options MATH_EMULATE# Support for x87 emulation options INET# InterNETworking options MFS # Memory filesystem options "COMPAT_43" # Compatible with BSD 4.3 [KEEP THIS!] options UCONSOLE# Allow users to grab the console options FAILSAFE# Be conservative options MFS_ROOT# Use a memory file system as root. options MFS_ROOT_SIZE=2048 # Space for MFS root filesystem. options INIT_PATH="/gizmo" config gizmo controller isa0 device npx0at nexus? port IO_NPX irq 13 device sio0at isa? port IO_COM1 flags 0x10 irq 4 device ed0 at isa? port 0x300 irq 11 iomem 0xd8000 pseudo-device loop pseudo-device ether Nice and simple, but after the ROOTDEVNAME changes, it cannot work. Sulk. The ROOTDEVNAME stuff needs to be fixed to allow this. Local disks and disk controllers should be optional. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Math emulation is broken in sys/i386/isa/npx.c
Bruce Evans wrote: > >Rev 1.67 of npx.c changed a #ifdef SMP to #ifdef 1, preventing the > >test for the hardware coprocessor. This breaks support for 386 processors > >without math coprocessors. Grrr. > > It was also broken a month ago by changing TARGET_DEFAULT from > (MASK_NO_FANCY_MATH_387 | 0301) for gcc to 0301 for egcs. This mainly > permits egcs to emit fsqrt instructions. This can be worked around > by using the GPL'ed math emulator or rebuilding everything affected > with CFLAGS+=-fno-fancy-math-387. Well at least at that time I could _boot_ the kernel. Now it just hangs. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Math emulation is broken in sys/i386/isa/npx.c
Rev 1.67 of npx.c changed a #ifdef SMP to #ifdef 1, preventing the test for the hardware coprocessor. This breaks support for 386 processors without math coprocessors. Grrr. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Porting Greg Lehey's rawio.c from FreeBSD to Linux...
Brad Knowles wrote: > On Sat, May 1, 1999, Greg Lehey wrote: > > >I don't really understand why you ask a FreeBSD group about it; it's a > >Linux issue. > > BTW, I asked here in addition to many other places, including the > linux-kernel mailing list, comp.os.linux.misc, and at least one person > who's got some other Linux benchmarking tools and is relatively > knowledgable on the subject. This is just the first place I've asked > where I've gotten any semi-intelligble answers so far. There's a moral there somewhere. 8-) -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: gcc
Jordan K. Hubbard wrote: > I've just built the world and kernel from egcs-2.91.62 and it > seems to work pretty well. I haven't really stress the system > all that much yet, but it hasn't misbehaved in any way yet. > > - Jrodan Since 4.0 was only recently branched, now seems like a good time to start using egcs as the system compiler, even if things are a bit bumpy for a while. Many people who started using -current during the 2.X vs 3.0 time can use 3.X-stable without losing much, if anything. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: adding DHCP client to src/contrib/
Steve Kargl wrote: > David's original email said he was going to commit without giving > a justification. I call it bloat, then the justifications pour in. > I'm now convinced it may be a good thing with a security audit. > > However, if every committer starting to push his (pet) software > as candidate for the base distribution, then the base will > grow without bounds. How long did it take to kill tcl from > the base distribution, and how long will it take to kill f2c? IMHO, "Just Do It". Ask David. 8-) -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: adding DHCP client to src/contrib/
Steve Kargl wrote: > David O'Brien wrote: > > > These should be left has ports. > > > > Explain how I am to install FreeBSD at my campus when DHCP has been > > mandated. Many univ. are moving in this direction. > > > > Maybe, support WC by purchasing the cd-rom? > > Convince your University to get a large quantity of cd-roms > from WC and resell the disks to the students? Or convince FreeBSD developers to simply add a DHCP client to the base sources and build a boot/install floppy with that functionality. No user cost. No user hassle. Why not?! Sigh. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: How many people use VI? This is unbelievable..
Chris Csanady wrote: > I unfortunately have a lot of data to type in, and to my surprise > the keypad is unuseable in vi. It doesn't even work in vim. Thank > god it works on Irix--I thought I would be using ee. > > Anyways, here is what happens when I type the digits 1-9 on the > keypad while in insert mode.. FWIW, this message is being edited with vi on a 2.2.8-STABLE machine rlogged in from a dxterm running on an OSF/1 box. The keyboard is one of DEC's LK401 things with the funny "Do" keys etc from back when VAX was just a twinkle in PDP's eye. I have TERM=vt100 in my FreeBSD environment, dxterm configured with the "Numeric Keypad" option checked and vt100 emulation, so keypad keys are 0.123456789, just like you'd expect. It's not vi that's the problem, just your termcap setting doesn't match the keyboard. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: more about yield() versus sched_yield()
Peter Dufault wrote: > > I've got a synch_yield() in kern_synch and a call into it from yield() > > in kern_thread that duplicates the yield() behavior for the non-RTPRIO, > > non-sched_yield() condition. synch_yield() also KASSERTS > > that p == curproc since nothing else makes sense. > > While we're discussing yield here's a question. > > The difference between yield() and sched_yield() is that yield unconditionally > yields while sched_yield() won't if you are the highest priority process > and the only process in your run queue. Does anyone know the > reuirements on yield() and would it continue to function for us if > it worked the same as sched_yield()? FWIW, the yield syscall is _not_ built into libc, so I doubt there will be anything that actually uses it. I think you should just keep sched_yield(). -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: btokup().. patch to STYLE(9) (fwd)
Russell L. Carter wrote: > Come on John, this has *meaning*. For or against -Wall > *stands* for something! We have constitutional procedures > to solve this thing! The "constitutional procedures" just stomp on things because the few who complain the loudest drown out those who silently or not-so-loudly agree. Ask yourself: in the last 6 months, how many things have been shot down and what has survived? From my point of view, not much progress has been achieved. As far as I can see, FreeBSD has reached critical mass and for each new developer coming on board, one drops off or goes inactive. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: btokup().. patch to STYLE(9) (fwd)
Greg Lehey wrote: > I don't think they're a good idea. Sure, I don't like style(9), but > if we're going to overhaul it, we should do it properly. Given the > diversity of opinion expressed every time anybody has tried the > smallest change, I don't see that happening, so why don't we just > forget the whole thing? Do you mean "forget changing style(9)" or "forget style(9) and delete it"? I think you probably mean the former, despite the fact that I was hoping for the latter. 8-) I can image a new subscriber to this list reading a few of these messages and thinking: "why would I want to use an OS developed by these people?". We spend so much of our time looking up our own collective asses searching for the meaning of life that it is no wonder FreeBSD doesn't feel like it has a clear direction for the future. All people seem to want to do is stomp on others who try to contribute something. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: btokup() macro in sys/malloc.h
Nate Williams wrote: > > Fixing warnings with bad casts is a problem, sure, but asking people > > to write code without casts (if possible) that will compile cleanly with > > -Wall is a reasonable thing to ask IMO. > > Agreed. But most of the new code written does indeed compile with > -Wall. It's the code we've 'inherited' that doesn't. OK, so we can review the fixes and improve things for the future. > > In my experience, the resulting > > code tends to be more portable across architectures with different > > pointer/long sizes and endian-ness. > > This is where I disagree. Too often people cast away the bugs and end > up with overflow and sign problems. We still have Bruce to review code for inappropriate casts etc. Try and stop him. 8-) -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: btokup() macro in sys/malloc.h
John Polstra wrote: > Bah! You might be able to hit Bruce over there in oz. But to hit me, > you'd need an ICBM. Give me purity or give me death! Bwahahahahah! Nah, I even tried poisoning Sydney's water with something I can't spell, but even that didn't kill off Bruce. The government told people not to drink the water. Sigh. My fallback strategy was to win the Olympics for Sydney and then hope they get bombed. Time will tell... -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: btokup() macro in sys/malloc.h
John Polstra wrote: > On 28-Jan-99 Bruce Evans wrote: > > Nah, style(9), not to mention the example of btokup() in Lite1 and Lite2, > > requires paretheses here (in btokup(), and probably in the bad example in > > style(9), because the expression would be really confusing without them :-). > > Hear ye, hear ye! Be it here noted and archived for all eternity that > on January 27, 1999 Pacific Time, John Polstra was, for one fleeting > moment, purer than Bruce! :-) OK, so now we have to shoot you too. Oh well, so be it Are there any others who would like to join these purists? Come on, we have bullets for you all... -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: btokup() macro in sys/malloc.h
Nate Williams wrote: > > Anyway, if we're going to -Wall'ify the kernel (as we should) > > then we need to update sytle(9) to reflect that. > > > > In fact, style(9) should say: > > > > If at all possible, your code should compile without warnings > > when the gcc -Wall flag is given. > > I disagree. As has been shown many times in the past (and I suspect the > down-under constituent will show that at least a couple of the I think you must mean the "Sydney-down-under constituent". There *is* a difference. 8-) > 'warnings' fixes will be wrong and hide bogus code), making -Wall a goal > causes people to cover up bad code with bad casts and such. > > '-Wall' is *NOT* a good design goal. Fixing warnings with bad casts is a problem, sure, but asking people to write code without casts (if possible) that will compile cleanly with -Wall is a reasonable thing to ask IMO. In my experience, the resulting code tends to be more portable across architectures with different pointer/long sizes and endian-ness. Just my 0.02, and I hate style(9) anyway. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: i386 a.out LKM support now an option..
Peter Wemm wrote: > However, the thought has occurred on many occasions that it might be an > idea to make a stand on this and remove the LKM build support. It will > clean up a few interfaces. If this doesn't happen for 3.1, it's definately > on my agenda for after the branch. Converting the common LKM's to kld > modules is pretty easy, and even the ones with custom load/unload code are > not too hard. I'd be interested to get a feeling for whether this should > be done for 3.1 or later. (Remember, OSS have a KLD version now for 3.0). I'm a fan of the new KLD system, so removing LKM build support is IMHO the right thing to do. I've been working on an embedded system which boots from a 2Mb flash chip without a filesystem. Before KLDs came along, I couldn't use LKMs for I/O devices because of the overhead of having to ship GNU tools too. Now all custom code lives in KLDs which get loaded by the application which replaces init and a simple 20 line kernel config file suits all target hardware versions. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
