Date: Mon, 8 Sep 1997 13:57:47 -0700 From: Jonathan Mini <j_mini@efn.org> To: Helmut Wirth <wirth@zerberus.hai.siemens.co.at> Cc: emulation@FreeBSD.ORG Subject: Re: Doscmd, debugging with gdb Message-ID: <19970908135747.62711@micron.efn.org> In-Reply-To: <3413F05C.41C67EA6@zerberus.hai.siemens.co.at>; from Helmut Wirth on Mon, Sep 08, 1997 at 02:32:28PM %2B0200 References: <3413F05C.41C67EA6@zerberus.hai.siemens.co.at>
next in thread | previous in thread | raw e-mail | index | archive | help
Helmut Wirth stands accused of saying :
> Hello,
> I have problems debugging doscmd with gdb. I would appreciate any hints
> how to do this. Here is the situation:
>
> Doscdm needs the lowest 1MB of virtual addresses for the DOS (VM86) -
> applikations to run. The emulator therefore resides at addresses higher
> than 1MB. This is done with a trick: A doscmd loader is started (this
> is the command one types in) and the loader in turn expands its data
> area and loads the doscmd.kernel starting over 1MB (actually its start
> address is 0x110000). doscmd.kernel is the emulator itself, it then
> proceeds to initialize the VM86 system. (In future we may need to load
> doscmd.kernel even higher, when DPMI emulation runs).
no we don't. ;P Just assign people addresses mapped above the emulator's
kernel. For a good example, QDPMI is a DPMI host that resides within the range
of 530K (or so) to the HMA just over 0x110000) (the HMA is actaully over 1M,
and is accessed by a (theoretical) bug in the 286 and up where Real Mode doesn't
act like the 8088/8086)
IMO, an excellent way to proved blocks of memory for DPMI wuold be to simply
mmap() it. This allows you to leave the kernel where it is, and just pass the
DPMI clients addresses that are within your newly mmap'd region. This is
probably incredibly obvious to those informed, but it's jsut a simple example
of how to implement in DPMI in a way where the doscmd kernel need not be
relocated.
> The problem: Starting doscmd under gdb loads the symboltable of the
> loader, not of doscmd.kernel. This is easy to solve (symbol-file ..).
> There are other troubles (with the signals, for example,..) but there
> are solutions for this too. I can trace into doscmd.kernel, load its
> symbols, list the functions, handle the signals correctly (nostop, pass
> for SIGBUS) and continue the program. But I cannot set breakpoints!
>
> I tried the following:
> 1) load doscmd under gdb, set breakpoint before call to doscmd.kernel
> entry, step into doscmd.kernel. If I then try to set a breakpoint
> gdb accepts it, but when I tell it to continue, it cannot set the
> breakpoint. ("Cannot set breakpoint, bad address 0x....).
> 2) Attach to the running doscmd. gdb attaches fine, I can read the
> symbol table using the symbol-file command or the -symbol option.
> Doscmd stops when gdb attaches itself, and I can examine the
> registers and memory. But again it cannot set any breakpoints, the
> same error as under 1) occurs.
>
> I think the reason for this is, that ptrace knows the text segment of
> the original loader, and it refuses to set breakpoints into what it
> sees as the data area of a program.
>
> Btw: doscmd.loader is linked as a normal ZMAGIC process, doscmd.kernel
> is linked as NMAGIC process.
>
> Has somebody an idea how to solve this? It would greatly enhance my
> productivity :-).
>
> Thank you
> --
> Helmut F. Wirth
> ---------------
> E-mail: hfwirth@ping.at
> E-mail (at work): wirth@zerberus.hai.siemens.co.at
> Tel. : +43-1-1707-37610 (at work)
> FAX : +43-1-1707-57602 (at work)
--
Jonathan Mini (j_mini@efn.org) Ingenious Productions
Software Development P.O. Box 5693
Eugene, Or 97405
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970908135747.62711>