Date:	Fri, 19 Aug 94 17:30:53 +1000
From:	junaid AT monu6 DOT cc DOT monash DOT edu DOT au (Mr A. Walker)
To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	GDB

	Well, i 'm greatfulreally happy that gdb413 has made it to MSDOS.
Unfortunately it seems that there is a problem with calling functions frmdebuggee functions
from the command line of gdb;  eg  p func()
	This executes func(), but the program cannot be continued.
	Also quiting out of the help topics gives a segv.
	While we're at it doing a list of some source code doesnt have a
newline at the last line, so the gdb prompt is appended to the las t source
line.
	Otherwise gdb seems to work rather well, even C++.  Are others haveing
this problem, or is it just me?

	Also gcc and friendso32 doesnt seem to use emy extended memory when only XMS is
aviailable thru HIMEM.SYS (eg no VCPI thru emmqemm).  I obseexperience a  much swapping
unless i use qemm or emm386.  The go32 sources seem to have a XMS driver
interface.
	I'll try The hHIMEM.SYS i'm using is the one distributed with DOS 6.0, but
DOS 5.0 HIMEM>SYS.SYS doesnt 'work' with go32 either.
	
	I'm going to try and see how gcc goes with a no raw DOS, with no HIMEM.SYS.
Is this the VDISK method aka bios extnedended mem alloc?

	BTW what is the speed idifference in execution speed and port I/O
for raw, XMS, VCPI and DPMI (pono port emulation)?  What about 

	Lastly one troubling fact is NULL ptr ointer access doesnt cause a
segv (data segment starts at virtual address 0?).  A Bit dissapointing, but
i suposse fsdb can help here.

	Also for those that didnt realise, malloc'ed data is executable in
all enviornments, which is a blessing.

	Well, i'd be greatful for any fixes of workarounds that people 
	could provide.

	Regards, 
	JuadJunaid.

- Raw text -