Date: Sat, 16 May 1998 23:18:14 +0800 From: Peter Wemm <peter@netplex.com.au> To: Bruce Evans <bde@zeta.org.au> Cc: current@FreeBSD.ORG, dyson@FreeBSD.ORG, kkennawa@physics.adelaide.edu.au Subject: Re: libc corruption Message-ID: <199805161518.XAA04319@spinner.netplex.com.au> In-Reply-To: Your message of "Sat, 16 May 1998 23:34:39 %2B1000." <199805161334.XAA22512@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > >> >This is the present situation and it's not working very well. > >> > >> It isn't the present situation. We commit the tables to src/sys and > >> use some tables from <sys>, some from src/sys/sys, and even some from > >> src/sys/kern (see src/usr.bin/kdump/kdump.c). We only generate the > >> tables on the fly for truss (see src/usr.bin/truss/Makefile). > > > >I'm talking about libc.. The syscall stub list is generated on the fly > >and the binary interface is affected. > > I'm talking about libc and the rest of the userland build too. The > syscall stub list (syscall.mk)is not generated on the fly. It is > generated together with syscall.h, etc., by running `make init_sysent.c' > in src/sys/kern and committing the results. Yikes, I was not paying enough attention when syscall.mk came in. I wasn't aware of it's purpose. IMHO, it should be in lib/libc/sys or lib/ libc/i386/ somewhere. > Since this is not automatic, > errors are often made the binary interface is not affected consistently > like it should be. I would argue that a change to the binary interface should be a deliberate thing, not something that's a side effect of a kernel change. I'd be happier if syscall.mk was generated by something under the libc build area when the committer chooses to build it from syscalls.master and otherwise seperate to the kernel. > Common errors include: > - forgetting to commit some of the changed files. I'd be guilty of that for the signanosleep nuke. I would have missed syscall.mk since I didn't know about it. > - not bootstrapping the changes properly (syscalls.master must be committed > first and then used to regenerate syscall.mk, etc. Otherwise the Id for > the source file in the generated files is garbage). Yes, a common problem, but it's hardly going to break your shared libraray linkake. Oh, I forgot, you don't like them anymore. > Bugs include: > - src/sys/kern/Makefile doesn't know about syscall.mk. Yes. > - checking out generated files sometimes breaks dependencies by clobbering > timestamps. CVS tries to be smarter in that it checks out files with their commit timestamps if there are no local modifications. I could imagine that this might be problematic if all the *syscall* files were wronly committed in one go, but the extent of the damage is limited to what happens if somebody tries to do a make of init_sysent.c or something in src/sys/kern, something that nobody would normally do unless syscalls.master was changed. > Bruce > Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805161518.XAA04319>