CURDIR it has been built without an obj directory; however if it is in
neither of those places, we expect it to be in DESTDIR.
Yes Bruce, I know this is broken because the host is not supposed to be
the same as the target, but we need to get the hosted build working
properly first before even attempting a cross compiled operating
system build. That will need to concept of TOOLSDIR or something that
can be mapped to DESTDIR in the case of a hosted build and set to the
installed tools in a cross compiled build. Later, later, later!
perl executable from overriding the object directory path search where
perl is most likely to be. Most people haven't seen this because it
defaulted to /usr/bin/perl which might be OK as a fallback, but when
bootstrapping a new version (or the *first* version on alpha), we don't
really want to use /usr/bin/perl.
This is a result of discussions on the mailing lists. Kudos to those who
have found the issue and created work-arounds. I have chosen Tor's fix
for now, before we can all work the issue more completely.
Submitted by: Tor Egge
possibly non-open devices, and we don't want to restrict dumping
to swap devices anwyay. It is especially invalid to call d_ioctl()
in non-process context for panics. d_psize() can be called on
non-open devices, at least on non-SLICED ones that support d_dump(),
and setdumpdev() has depended on this for a long time although it
is probably wrong, but even d_psize() can't be called in non-process
context - that's why dumpsys() depends on previously computed values
although these values may be stale. The historical restriction to
devices with dkpart(dev) == SWAP_PART should go away.
kernel's) curproc is null. This fixes endless recursion in
xfer_umem() for attempts to read from user addresses, in particular
for attempts to read %fs and %gs from the pcb for `info reg'.
is used in the dependency list for ${DEPENDFILE}. `make depend' was
broken for a few days. `make world' only uses `make depend' when
NOCLEAN is defined, so only a few people noticed the bug.
Submitted by: mostly by jmg
to attempt to unblock SIGCHLD, but we actually want to unignore SIGPIPE.
Obtained from: OpenBSD
Finished conversion from sigvec to sigaction (don't assume that sa_mask
is a scalar...). Didn't convert from sigblock to sigprocmask. Didn't
fix missing error checking for sigaction...
gas for each target format. So for m68k targets that means several
gases. I wanted a m68k gas for VxWorks which uses aout in sun3 big
endian format, cross compiled on i386 under FreeBSD using libraries
supplied by DEC and intended by them for cross compilation on Alpha
under OSF/1. And it actually works!
instead of long long and unsigned long long. Really they should be
quad_t and u_quad_t, but that would require sys/types.h and this
header only includes machine/types.h. The difference here is that
int64_t and u_int64_t on alpha are long and unsigned long, not
long long etc. This is required to pass gcc's type checking where
long != long long even though they are the same size of alpha.
umount() was trying to stat() the mountpoint, this would fail if the
mountpoint was a NFS mountpoint, and the fallback code would try and pass
a hostname:/dir path as the mountpoint to unmount(2), which would fail.
This whole stat() of the name supplied on the command line business is
trouble as it'll wedge on a hung NFS mount.
I'm not entirely sure why we are not simply looking up both arguments
in the mount table and doing the right thing without accessing the
filesystem. It seems that we're going to a lot of trouble to allow
mountpoints on symlinks and other wierd things.
PR: 1607
the only common usage of utrace (the possible problem with this
commit) is with malloc, so this should be a real problem. Add
the various NetBSD syscalls that allow full emulation of their
development environment.
apparently, unlike the IDE or SCSI CDROM drivers, this is magically
special-cased for audio CDs. This also might explain what happened
with scd (Sony) CDs also since I made the same change there. A follow-up
commit will fix that. Thanks, Dave!
PR: 6576
Submitted by: Dave Marquardt <marquard@zilker.net>
