> > > I see. It looks like mbrola is an a.out executable. Do you, by any
> > > chance, have some of the COMPAT_* options disabled in your kernel?
> >
> > I only have COMPAT_14 as far as prior NetBSD versions go.  I had no idea
> > that I was dealing with a precompiled binary.  (Odd, I can't find any
> > COMPAT_AOUT options in GENERIC, much less my custom kernel config---but I
> > have COMPAT_14...  I cannot find COMPAT_AOUT in options(4), either.
> >
> > So, I need COMPAT_13 and (I assume) COMPAT_AOUT added to my kernel config.
> > I assume that in addition to recompiling a kernel, I'll need to install
> > the ...pkgsrc/emulators/compat1{3,4} packages.  Am I missing anything?
> > Is there a way that mbrola can be marked as depending upon these?
>
> I doubt it. We did that for one packge that needed a particular
> emulation to _install_ it (I forgot which), but in this case, it
> doesn't affect the build. We don't want to place unnecessary
> requirements on the build and package stage. It would be possible to
> add an INSTALL script, if you think that would help. The INSTALL
> script typically isn't run at all, though, if you build from source.
>
> Here's a start, if you want to play with that...
>
> if ! nm /"`sysctl -n machdep.booted_kernel`" | grep -q __fstat13 ;
> then echo WARNING ; fi


> There isn't any good reason, in my opinion, to run a kernel without
> the COMPAT_NN options (at least on a system intended for general use).

(Except COMPAT_42?  (^&)

Well, one response is that my system isn't intended for general use.  It's
intended for my personal use.  Up till now, this has not included running
1.3 binaries on a 1.5 kernel.  Now that I see that mbrola doesn't come in
source form, and only a handful of voices use mbrola, I may just pass on
installing it.  (Perhaps, one day, if they release a version that runs on
the then-most-recent major kernel release...or if they release the sources
so that it can be recompiled natively...(^&)


> The truly naive user wouldn't be running a custom kernel anyway. It
> looks like you've run into the principle, "We give you enough rope to
> hang yourself"!

Yeah, perhaps.  Everyone's got to have a hobby, after all...  I certainly
would rather have the rope that I was given, here, than have had the
option withheld.  (^&


> > I'm a little surprised that this problem shows up as an FPE.  Is that a
> > design feature for a.out binaries (or for trying to run them on an ELF
> > NetBSD system)?
>
> I'm sure it isn't. What else is supposed to happen, besides dump core,
> when an application invokes a non-existent syscall? If you begin to

Well, it's doing with code something analogous to indirecting through a
bogus pointer.  How about a segfault?  Preferably accompanied by a kernel
message/system log about a bogus syscall.  Or would I have had that, if
I'd turned up a higher level of checking in my kernel?


> debug the core file with "gdb .../program .../...core", and give the
> "bt" command, you can usually see right away what's wrong, else
> kdump/ktrace really shows it.

I did that a couple of days ago (with gdb/bt (well, ddd/bt)), and peeking
at the assembly code where it crashes.  It blows on an IDVIL instruction
(I didn't bother to check the register/memory values; presumably
divide-by-0).

It's fine that it dumped core.  It's just confusing that the way that it
says ``this is an obsolete, or a non-existant, system call'' is to divide
by 0.  Printing something through the system log to the console or
xconsole and dumping core w/o pretending to do arithmetic would have been
less confusing.  IMHO.  If it needs to use a signal for this, FPE would
not be my choice.  (^&


(kdump/ktrace don't occur to me as normal diagnostic tools.  Maybe they
should, though...)


  "I probably don't know what I'm talking about." --rauch@eecs.ukans.edu