From: sandmann AT clio DOT rice DOT edu (Charles W. Sandmann) Subject: DPMI exec bug To: djgpp AT sun DOT soe DOT clarkson DOT edu (DJGPP Mailing List), dj AT ctron DOT com (DJ Delorie) Date: Sun, 12 Dec 1993 18:07:57 -0600 (CST) This was a nasty one (about 5 hours worth). Thank goodness for OS/2 register information on DPMI pukes. The real bug is in GO32, but there is a reasonable workaround for those of you without the tools to rebuild GO32. What was happening is that the high word of EBP was being loaded with a non-zero value before the exec took place, and when the second GO32 program was run the latent GO32 bug kicked in. Okay, first the GO32 patch (the real fix): *** dpmi.as_ Sun Aug 29 12:54:20 1993 --- dpmi.asm Sun Dec 12 17:22:20 1993 *************** *** 136,139 **** --- 136,140 ---- xor ax,ax @@done_initDPMI: + xor ebp,ebp pop di pop si And for those of you without the tools to rebuild GO32, you can get DJLSR111.ZIP, extract libsrc\c\dos\exec.c, and patch as follows: *** exec.bak Sat Nov 27 21:36:04 1993 --- exec.c Sun Dec 12 17:42:20 1993 *************** *** 154,157 **** --- 154,158 ---- r.x.bx = parm_la & 15; r.x.ss = r.x.sp = 0; + r.x.bp_hi = 0; _go32_dpmi_simulate_int(0x21, &r); if (r.x.flags & 1) Since the r structure is on the stack, ebp gets loaded with whatever happens to be there, which explains the intermitent failure. If the upper word was by luck zero, then it worked, if not it puked. Using the patch to GO32, I was able to use "make" under DPMI without any modifications to make. Using the distributed GO32, I was able to rebuild make from the source distribution, replacing the patched exec.o, and the resulting make also worked under DPMI. This is all a side effect of the "LEAVE" instruction on a 32 bit stack and 16 bit code segment that I was not aware of, but now painfully am... rom djgpp-bounces Mon Dec 13 01:08:56 1993 Received: by sun.soe.clarkson.edu (4.1/SMI-4.1) id AA13233; Mon, 13 Dec 93 00:57:12 EST Return-Path: Received: from sol.ccs.deakin.edu.au by sun.soe.clarkson.edu (4.1/SMI-4.1) id AA13223; Mon, 13 Dec 93 00:57:00 EST Received: from bregor.cm.deakin.edu.au (bregor.cm.deakin.edu.au [128.184.80.157]) by sol.ccs.deakin.edu.au (8.6.4/1.4) with SMTP id QAA08016 for ; Mon, 13 Dec 1993 16:54From djgpp-bounces Mon Dec 13 03:08:56 1993 Received: by sun.soe.clarkson.edu (4.1/SMI-4.1) id AA13826; Mon, 13 Dec 93 02:51:27 EST Return-Path: <@TWNMOE10.Edu.TW:u7711501 AT bicmos DOT ee DOT nctu DOT edu DOT tw> Received: from omnigate.clarkson.edu by sun.soe.clarkson.edu (4.1/SMI-4.1) id AA13822; Mon, 13 Dec 93 02:51:24 EST Received: from twnmoe10.edu.tw by omnigate.clarkson.edu with SMTP (PP) id <01228-0 AT omnigate DOT clarkson DOT edu>; Mon, 13 Dec 1993 02:53:09 -0500 Received: from NCTU.edu.tw by TWNMOE10.Edu.TW (IBM VM SMTP V2R2) with TCP; Mon, 13 Dec 93 15:42:41 EST Received: by bicmos.ee.nctu.edu.tw (16.7/16.2) id AA00731; Mon, 13 Dec 93 15:40:26 +0800 From: Jih-Shin Ho Subject: Re: reporting bugs in gcc To: stevev AT miser DOT uoregon DOT edu (Steve VanDevender) Date: Mon, 13 Dec 93 15:40:26 EAT Cc: djgpp AT sun DOT soe DOT clarkson DOT edu (djgpp) In-Reply-To: <9312120710 DOT AA00410 AT miser DOT uoregon DOT edu>; from "Steve VanDevender" at Dec 11, 93 11:10 pm X-Mailer: ELM [version 2.3 PL11] Message-Id: <"omnigate.c.253:13.11.93.07.55.45"@clarkson.edu> > > Bob Babcock writes: > > > What you should do is get the latest gcc (2.5.6 at the current time) > > > and rebuild cc1 to see if it is still a problem. > > > > I was afraid that would be the answer. Could you estimate how much disk > > space is required to do this? Could I instead build a cross-compiler under > > Unix? > > You will need 40-50M of free space to compile GCC, if you > economize a bit (clear out the unused config files; build just > the C compiler in stages 1 and 2 and only compile cc1plus in > stage 3 after removing the stage1 directory, etc). > > I wouldn't recommend trying to cross-compile on a non-DOS box. > It's easier to get it right if you build the normal compiler. > I build every djgpp binary file using cross-compiler. The machine I use is HP9000/700 workstation. All executable files work fine. the most important thing is that I don't need to worry about shell. -- Jih-Shin Ho