Subject: Is anyone making native netBSD a.out binaries? Or using ECOFF nlist()?
To: None <port-pmax@sun-lamp.cs.berkeley.edu>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-pmax
Date: 08/29/1994 23:44:19
I'm stuck making forward progress. Anything more I want to do
(netstat, kgmon, ...) requires libkvm.  This in turn needs the NetBSD
nlist. Which doesn't work on cross-compiled ecoff binaries.

I'd happily substitute an Ultrix nlist and continue; except
that the NetBSD libkvm.a doesn't use nlist(3), but instead
uses a private interface to the NetBSD implementation of nlist().

From where I'm sitting -- having a cross-compiled kernel in
ecoff format -- that's an unfortunate design decision.

Moving to NetBSD kernels is going to be a big step:
as far as I can tell, I'll need to write a native disklabel,
bootstrap sector, and then try booting a native-aout kernel.

Has anyone tried this? If so, are there binaries (e.g., for
a gas and gcc) that I can use, or will I have to bootstrap my own?

Personally, I'm tempted to just smash the private kvm structures so they
keep the filename of the "symbol file" and have kvm_nlist()
call nlist() with that string, rather than call __fdnlist().
To me (and I emphasize, it's just me!) that seems like a
violation of an otherwise clean abstraction  and interface.

I realise that changes may well have a small, perhaps infinitesimal,
chance of being merged back into anyone else's NetBSD source tree.  If
that is the case, there's not much point trying it.  *Is* there any
point?


--Jonathan

------------------------------------------------------------------------------