Date:	Fri, 28 May 93 11:08:33 EDT
From:	engdahl AT brutus DOT aa DOT ab DOT com (Jon Engdahl)
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	page fault handler problem

I was working on spawn and make last night (way too late) and ran into
a problem with a page fault. I have make-3.65 going through the motions
of doing a simple build (the actual spawnvpe call in my new code in
turbo_assist is commented out at the moment). After doing several dummy
compiles, the page fault handler got stuck just after backing out of a
call to spawn. The bad virtual address was something like e0014xxx. The
page fault handler was getting to the piece of code that starts with
"if(vaddr>= 0xf0000000)".  I believe that this is the part that maps
pages onto the first meg of physical RAM.  The problem is that the page
fault handler evidently failed to map a valid page, so when it
returned, the bad reference caused another fault right away, and now we
are stuck in a loop. I have a hunch that the problem has something to
do with the "page_[out|in]_everything" that I just completed.

There are several possibilities that I am considering:

	- I am generating a bad address, and I have found a bug in the
	page fault handler.

	- I am generating a bad address, and I have stabbed the page
	fault handler.

	- the address is legit, but I have stabbed the page fault handler.


Answers to the following questions will help me narrow this down more quickly:

	- does anything in go32 or DJ's library legitimately access
	memory in the F0000000 area? (E0000000 virtual) - at least if I
	am not using graphics or anything fancy?

	- if not, is there any reason why I cannot ifdef out the
	F0000000 handler for now, and let this be handled as an illegal
	address fault?

Also, if anyone can tell me what I have to do to get source lines
working again in debug32, I would be most grateful. I tried an older
version of cc1, probably 2.3.3, and it didn't give me source either,
but I wasn't real sure what rev it was.

For anyone who is curious as to what I am doing, I have added "spawn*"
to GO32, and have written a "stubs.c" that implements enough of fork,
exec*, wait, and exit to allow GNU make to run. The trick is that, in
many programs, the child process doesn't do much besides call exec,
which allows me to implement fork as "create thread". You have to be
careful that the child does not clobber any of the parent's globals
before it calls exec. The only changes required to "make" so far were to
fix one clobber of a global (child->pid), and add ifdefs to handle DOS
path names. I may have to do something with "pipe" before I'm done.

If anyone can see any major pitfalls that I am headed for, please let
me know.

Jonathan Engdahl, Sr. Project Engineer | engdahl AT aa DOT ab DOT com N8XVY 313-998-2450
Allen-Bradley Co.                      | A Rockwell International Company
555 Briarwood Circle,                  | Industrial Communication Networks
Ann Arbor, Michigan, 48108, USA        | system design, software, ASICs

- Raw text -