Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!aplcomm!uunet!mcsun!ukc!pyrltd!mwuk!tony
From: tony@mwuk.UUCP (Tony Mountifield)
Newsgroups: comp.os.os9
Subject: Re: Diffs between OS-9 2.2 / 2.4 ?
Message-ID: <467@mwuk.UUCP>
Date: 28 Jun 91 08:21:23 GMT
References: <1991Jun27.140054.13331@unhd.unh.edu>
Organization: Microware Systems (UK) Ltd., Winchester, UK.
Lines: 59

In article <1991Jun27.140054.13331@unhd.unh.edu> pss1@kepler.unh.edu (Paul S Secinaro) writes:
> 1.  What exactly does error #000:102 mean?  I know that UNIX, for
> example, will give a "Bus Error - core dumped" message if you try to
> use an improperly initialized pointer or otherwise bang up against the
> limits imposed by the MMU.  Does it mean the same thing in OS-9?  Or
> is it referring to some sort of hard error on the processor bus?

It means what you thought - an access through an uninitialized or
corrupt pointer. On systems with an MMU and the "ssm" module, this means
almost anything outside your own program and data space (or modules you
have linked to). Without an MMU, it will only happen with references to
non-existent physical addresses. If a user-state program gets a bus
error, the kernel catches it, and terminates the process cleanly with an
error 102.

> 2.  Could this type of error be caused by lack of upward compatibility
> from v2.2 => v2.4 of OS-9.

Quite likely. If a program is compiled with the compiler and libraries
from a later system, it will likely not run on an earlier system. The
other way round is OK though - I have binaries compiled for V2.1, and
they run fine on V2.2, V2.3 and V2.4.

> 3.  Could this program be trying to execute '030 specific code on the
> '020?  Can the Microware C compilers generate '030 specific code?

No. In fact the difference between an 020 and an 030 is only in the area
of the MMU. Our compiler never has reason to generate MMU instructions.

>     I realize that it's impossible for anyone to fully answer any of
> these questions without knowing a lot about the code itself.  I'm just
> interested in knowing if 1,2, and 3 are possible sources of trouble.
> Is there any way to setup DEBUG to go active on an error trap, or does
> it do this automatically (I've never used it much before).  Thanks

If you run a program under DEBUG (OS-9 user-state debugger) it will be
informed by the kernel if the program gets a bus error, and you will be
able to examine the memory, registers, etc. To do this on a program
called "test", do:

	debug test
	x -1

This will execute at full speed (the "g" command uses Trace mode, and is
much slower), and will stop at an exception such as bus error.

> Paul
> -- 
> Paul Secinaro             | Synthetic Vision and Pattern Analysis Laboratory
> pss1@kepler.unh.edu       | Department of Computer and Electrical Engineering
> p_secinaro@unhh.unh.edu   | University of New Hampshire     (603) 862-3287

Tony.
-- 
Tony Mountifield.                | Microware Systems (UK) Ltd.
MAIL:  tony@mwuk.uucp            | Leylands Farm, Nobs Crook,
INET:  tony%mwuk.uucp@ukc.ac.uk  | Colden Common, WINCHESTER, SO21 1TH.
UUCP:  ...!mcsun!ukc!mwuk!tony   | Tel: 0703 601990   Fax: 0703 601991
**** OS-9, OS-9000 Real Time Systems **** MS-DOS - just say "No!" ****