NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/sys/amiga/programm/13049

Text File | 1992-09-03 | 3.6 KB | 78 lines

Newsgroups: comp.sys.amiga.programmer
Path: sparky!uunet!haven.umd.edu!darwin.sura.net!Sirius.dfn.de!chx400!bernina!wild
From: [e-mail] (Markus Wild)
Subject: Re: GNU C and ixemul.library
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News System)
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
References: <[e-mail]>
Date: Thu, 3 Sep 1992 21:33:12 GMT
Lines: 66

In article <[e-mail]> [e-mail] (Simon Raybould) writes:
>I've been trying to port bash to the amiga using Markus Wilds GNUC 2.2.2
>most things seem to be working fine, automatic completion, history
>e.t.c.

With bash you face the following problems:
  - data/bss space is far larger than 64k, so you won't be able to use the
    -fbaserel mode, and hence can't make bash residentable with -resident.
  - due to this, you can't really emulate any fork() calls like I did in
    pdksh.

The inability to emulate fork caused me not to consider a bash port, but
you may be successful if you manage to get a working fork, good luck!! I'd
be very happy to toss ksh for bash, as bash is my usual shell that I use
on any Unix I get access to (it's usually the first action to ftp the
sources and compile a bash when I have to work on a new Unix ;-)).

>The problem is when a command is executed by bash, I get an "EMT trap"
>and bash exits returning to the CLI prompt. Not long later the amiga
>will usually crash.

I'd be very interested in which functions bash executes up to this point.
You may find out by using the tracer (see the README.TRACE file in the
2.2.2 distribution). For short, open two shell windows, in one do

   ..> flush
   ..> loadlib gcc:libs/ixemul.trace    ; this replaces ixemul.library
   ..> trace -m        ; you may have to use trace -m -i here

In the other start bash.

If the problem only occurs after bash has initialized, shown the prompt,
and you then try to execute a command, you should flush the library, load
the traceing library, but not yet execute trace in the first shell. Then
start bash, and as soon as bash shows the prompt, in the other shell start
the tracer. This trick speeds up debugging, since I'd imagine that bash
does thousands of ixemul calls until the real problem occurs.

>Any ideas as to what is causing this would help. I think this is an
>Emulator trap.

Corrupt stack? You can reasonably argue that bash is not placing any
emulator instructions into the instruction stream on purpose, so the trap
must be the result of a corrupted instruction stream. Such a corruption
can happen if returning to a corrupted stack frame.

>P.S. This is on a 68040 based amiga. If i run it on a 68000 based
>amiga, I get "bus error" when a command is executed. The difference
>may be to do with the MMU in the 040?

Looks even more like a stack problem then. Note: I know there are new
exception frames on the 68040, incompatible to those of the 68030. However,
I don't have documentation on these frames, so I couldn't incorporate them
into ixemul.library. If you happen to have such documentation, I'd be
glad if you could EMail it to me, and I'll try (won't be able to verify..)
to incorporate them into ixemul.library. It might be the case in your
specific problem, that ixemul rewinds the stack in a wrong way, ie. cleans
up too much or too many stack, and then the program resumes executing at
an undefined point.

-Markus

--
Markus M. Wild    -  [e-mail]  |  [e-mail]
Vital papers will demonstrate their vitality by spontaneously moving
from where you left them to where you can't find them.