Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!bcm!dimacs.rutgers.edu!seismo!uunet!mcsun!hp4nl!inducom!meindert
From: meindert@inducom.UUCP (Meindert Kuipers)
Newsgroups: comp.os.os9
Subject: Re: more linker problems
Message-ID: <2027@inducom.UUCP>
Date: 31 Jan 91 13:05:17 GMT
References: <1991Jan29.114204.1751@yogi.fhhosp.ab.ca>
Organization: Inducom Systems BV, Oss Netherlands
Lines: 66

From article <1991Jan29.114204.1751@yogi.fhhosp.ab.ca>, by edstrom@elmer.hsc.ucalgary.ca (John Edstrom):
> 
> 
> After reading the manual several times more closely I learned that the
> IOMan and the device driver share the same static storage area.  The
> problem comes from the fact that they don't know what each other are
> doing.

Not really, IOMan uses the driver's static storage for passing parameters
etc.

> 
> for example, if I use the device storage area to save some data like an
> input buffer (a la Dibble) it would look like this:
>  
> 	vsect
> inpntr	ds.l	1   * points to current position in buffer
> inbuf	ds.b	80  * body of buffer
> 	ends
> 
> The problem is that IOMan uses the same data section but uses different
> offsets which are defined in sys.l.  Thus, V_PORT is defined as $0 and
> so is inpntr.  So when the IOMan saves the device port address it overwrites
> my inpntr.  I could also have written the above code as:
> 
> So, my question is: how do I get my linker to respect IOMan's data sections?
> I would just declare a heap of junk bytes at the top of my vsect if I could
> find out how much space the IOMan and SCF filemanager needs to mangle.  Is
> that information available anywhere?

The linker collects all the vsects in all ROF's, and links them together
with the first vsect starting at offset zero. in your /dd/LIB directory
are several file like scfstat.l and drvs2.l etc. These contains vsects
with definitions of the driver static storage. One of these libs must be
the first on a linker command line like:

	l68 /dd/LIB/scfstat.l sc_driver.r -l=/dd/sys.l -O=sc_driver

for a standard SCF device driver. With the RDUMP command and its options
you can get a listing of the contents of the library files.
If your driver is for a custom filemanager things are a little tricky,
because you have to create this library file yourself. In the /dd/DEFS
directory (print all the files out NOW, you will learn a lot about OS-9)
you can find a file like scfstat.a or scfstat.d which is basically the
source for scfstat.l (or scfstat.r, the names sometimes differ). This source
refers to many other files, like io.a.

Microware sells a (non-supported) free driver pack for a small amount of
dollars. I think the listings of the makefiles alone are worth it and it
could have prevented a lot of your time. There is also a lot of driver
source code included for both SCF and RBF.

Good luck.

-------------------------------------------------------------------------------
  +-----+                  Inducom Systems B.V.
  |     <                  Raadhuislaan 27   NL - 5341 GL  Oss, Netherlands
  |  o  |                  P.O. Box 627      NL - 5340 AP  Oss, Netherlands
  |  INDUCOM SYSTEMS       Phone: (31)-(0)4120-41922
  +-----+                  Fax:   (31)-(0)4120-22640
  Specialists in OS-9, VMEbus and G-64

  Meindert Kuipers, Inducom Systems B.V.
  UUCP: meindert@inducom.UUCP        ...!uunet!mcsun!hp4nl!inducom!meindert
  -- Coming soon to a VMEbus system near you: VMEtro BusBusters --
-------------------------------------------------------------------------------