Date: Thu, 25 Feb 1999 11:14:51 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Dave Bird cc: djgpp AT delorie DOT com Subject: Re: I just wanted to assemble this old program under NASM.... In-Reply-To: <1lGPMoAteC12EwsX@xemu.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com On Wed, 24 Feb 1999, Dave Bird wrote: > At the moment there is a program prefix at START: which defines > the following things. (1) Sets up stack pointer and segment > registers (2) If true PM it would manage the transition from > 16Bit RealMode start-up through calling DPMI to set up the > protected mode segments and enter protected mode (3) It uses > XMS [or DPMI] to allocate about 40MBytes locked and provide > a simple 32bit variable pointing to it (4) then it calls ASM_MAIN. > On return it de-allocates and exits. > > Next it defines wrappers for various DOS calls with convenient > register-passing conventions for WriteChar, WriteString, > ConvNum, WriteNum and so forth. It also has a "Load" routine > to whack a complete data file into where the allocation pointer > points and update the pointer [using a 16KB transfer buffer > on the reads]. DJGPP's startup code and low-level library functions already do all that for you, and you cannot do the above yourself in a DJGPP program, because you will most certainly create a conflict with DJGPP internals. For example, the startup code already enters protected mode, so your code will not be able to enter it again. Also, as I told you in a previous message, any protected-mode setup that is not identical (or at least very close) to what the DJGPP's startup code does will almost certainly confuse any DJGPP debugger, including the one built into RHIDE. So any such ``prefix'' will have to assume that it's already in protected mode, and that memory allocation should be done via DPMI functions or through malloc, and pick up from there. Then and only then will it stand a reasonable chance of being debugged by DJGPP debuggers. > Would RHIDE's GDB type debugger be happy with this? it would > just follow the source across into filename.S which > contained ASM_MAIN ?? I think somebody said that NASM cannot yet generate debug info, so you might need to use Gas (and hence the AT&T syntax) to get full debug support in assembly code.