Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site nbs-amrf.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!zehntel!hplabs!hao!seismo!umcp-cs!nbs-amrf!libes
From: libes@nbs-amrf.UUCP (Don Libes)
Newsgroups: net.micro.68k
Subject: bus error, but why?
Message-ID: <363@nbs-amrf.UUCP>
Date: Mon, 14-Jan-85 15:11:12 EST
Article-I.D.: nbs-amrf.363
Posted: Mon Jan 14 15:11:12 1985
Date-Received: Sun, 20-Jan-85 06:26:24 EST
Organization: National Bureau of Standards
Lines: 29

I've wrote some C code that generates a bus error in the same spot,
consistently.  I don't think the C code (at least at the location the bus
error is reported) is very important, because the location moves when I add or
delete enough statements.  Also, its executed several times before it faults.

I've tried all the "classical" C debugging techniques (adding printfs,
deleting code and watching for the error to go away, etc...) but I'm down to
looking at the 68010 assembler (on a Sun).  Using stepi (in dbx), I can
single-step through the instruction.

It always a movl.  Here's an example:

	movl	a0(18),d0

When I execute this instruction I get a bus error.  What's mystifying is that
I can look at the memory pointed to by both operands with the debugger.
Additionally, the stack and everything else looks just fine.  What else might
a movl depend on?  The 68010 reference manual says a bus error will leave
condition codes set indicating the address in question, but how does one look
at the condition codes with dbx?

If it helps, the pc ends up two bytes into the movl, after the bus error.  I
can reset it to the movl instruction and get the bus error an arbitrary number
of times.  I ran the same piece of code on our VAX (running Eunice) just to
see what its debugger (sdb) would say, but it doesn't generate a fault at all!

Help!

Don Libes	{seismo,umcp-cs}!nbs-amrf!libes