From owner-freebsd-current  Wed Apr  5 13:48:05 1995
Return-Path: current-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id NAA29091
          for current-outgoing; Wed, 5 Apr 1995 13:48:05 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id NAA29075
          for <current@FreeBSD.org>; Wed, 5 Apr 1995 13:47:49 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id GAA30107; Thu, 6 Apr 1995 06:44:59 +1000
Date: Thu, 6 Apr 1995 06:44:59 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199504052044.GAA30107@godzilla.zeta.org.au>
To: current@FreeBSD.org, nate@trout.sri.MT.net, rgrimes@gndrsh.aac.dev.com,
        rkw@dataplex.net
Subject: Re: Genassym
Sender: current-owner@FreeBSD.org
Precedence: bulk

>I haven't looked at genassym, but assume that it uses the sys headers only
>as input text, or equivalently, conditional conpilation flags. If it makes
>any assumptions about kernel data structures, etc. it will eventually break
>in cross platform compilation. :(

You should like at it.  It's main job is to print the sizes of and offsets
in kernel data structures.  (It also gathers the defines for manifest
constants from scattered headers files that aren't all ready for inclusion
in assembler files, but this is easy to do in other ways.)

genassym can't work in it's present form in a cross platform environment,
so it's a waste of time to worry about how to build it in such an
environment.  genassym.s could be built as follows: replace genassym.c by
code of the form:

    long define_FOO = FOO;
    size_t sizeof_bar = sizeof bar;
    size_t offset_of_baz_in_bar = offsetof(bar, baz);

Compile this to an object file for the target using a cross compiler.
Write a post-processor to convert this file (nm file | awk ...).
nm outout is very easy to parse.

Bruce