Mail Archives: djgpp/1999/02/24/11:27:04
In message <Pine DOT SUN DOT 3 DOT 91 DOT 990224110518 DOT 22838A-100000 AT is>,
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> writes:
>On Tue, 23 Feb 1999, Dave Bird wrote:
>
>> OK, I'll try rhino-hide.... with some trepidation, because it
>> is another big complicated package to learn in order to get
>> to a fairly simple objective.....
>
>If you are serious about writing programs, you will eventually need to
>begin using some serious programmer's editor. The default editors (on
>any system) are just not good enough, IMHO.
I am already very happy writing large Borland C++ programs
in Borland's IDE; I had hoped I could get this intel-asm program
debugging with PM large memory allocation under GDB with simple
editors and a slightly different assembler (i.e. without needing
to stop and learn a whole new IDE).
In message <Pine DOT SUN DOT 3 DOT 91 DOT 990224110855 DOT 22838C-100000 AT is>, Eli Zaretskii
<eliz AT is DOT elta DOT co DOT il> writes
>
>On Wed, 24 Feb 1999, Dave Bird wrote:
>
>> >DJGPP programs *start* in 32-bit mode. You can't switch to/from real
>> >mode the way you're thinking in a djgpp program.
>> You mean "no program which does so can be defined in assembler,
>> assembled and linked, then fed to GDB......" :-?
>
>Probably not, at least not in the DJGPP port of GDB.
>Here's some background on how debugger support works in DJGPP.
>[.................................................concluding:]
>The debugging library was written specifically for DJGPP, with nothing
>else in mind but debugging DJGPP-style COFF images that run in a DPMI
>environment.
>
>From this description, it should become clear that the DJGPP debuggers
>are probably not good for debugging anything but DJGPP programs, or
>programs that at least look and behave like DJGPP ones.
Right. From this it is clear that the simplest and most sensible
way to achieve what I want is to make the prefix a 'C' program
which then calls asm_main rewritten in [Nasm] assembler. The CODE
part is well below 640K, in fact it's well below 64K. Obviously it
would me if GDB, and GNU-on-DOS, were designed to assemble and debug
anything then configured to particular DJGPP things within that;
but this wasn't it's primary purpose, and if it won't do so then
that's just my tough luck.
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].
Now we draw a line across the listing below all system interface.
ASM_MAIN is written to just start working as if all set-up
actions have been done, and to call convenient assembler routines
for its I/O and other system needs.
I suppose this is what I would want to do with the prefix
written in C, with a call to ASM_MAIN. Services could be
defined as C routines and exported, probably to wrappers
which gave them more convenient register passing conventions.
Would RHIDE's GDB type debugger be happy with this? it would
just follow the source across into filename.S which
contained ASM_MAIN ??
--
^-^-^-@@-^-;-^ http://www.xemu.demon.co.uk/
(..)__u news:alt.smoking.mooses
happy as a clam at high tide -. <_" .-._.-.
- Raw text -