Mail Archives: djgpp/1994/08/19/05:22:38
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 -