From owner-freebsd-emulation Tue Sep 9 12:43:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA00286 for emulation-outgoing; Tue, 9 Sep 1997 12:43:07 -0700 (PDT) Received: from atlantis.ping.at (a013.static.Vienna.AT.EU.net [193.154.186.13]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA00276 for ; Tue, 9 Sep 1997 12:42:57 -0700 (PDT) Received: from atlantis (localhost.ping.at [127.0.0.1]) by atlantis.ping.at (8.8.7/8.6.12) with SMTP id VAA00785; Tue, 9 Sep 1997 21:42:44 +0200 (MEST) Message-ID: <3415A6B4.41C67EA6@ping.at> Date: Tue, 09 Sep 1997 21:42:44 +0200 From: "Helmut F. Wirth" X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: Bruce Evans CC: emulation@freebsd.org Subject: Re: Doscmd, debugging with gdb References: <199709090457.OAA28185@godzilla.zeta.org.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-emulation@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bruce Evans wrote: > > There must be more to it than that, since gdb can set breakpoints > in shared libraries although it doesn't understand symbols in shared > libraries. Perhaps it is relocating text addresses by 0x110000 when > it should use 0. > > Bruce Bruce, I have investigated a little.. indeed there seems to be more. Here is the ktrace output from gdb in this situation: 524 gdb CALL write(0x1,0xe1000,0xc) 524 gdb GIO fd 1 wrote 12 bytes "Continuing. " 524 gdb RET write 12/0xc 524 gdb CALL ptrace(PT_READ_I,0x208,0x127b0c,0) 524 gdb RET ptrace 4031315/0x3d8353 524 gdb CALL ptrace(PT_READ_I,0x208,0x127b0c,0) 524 gdb RET ptrace 4031315/0x3d8353 * 524 gdb CALL ptrace(PT_WRITE_D,0x208,0x127b0c,0x3dcc53) * 524 gdb RET ptrace -1 errno 14 Bad address * 524 gdb CALL ptrace(PT_WRITE_I,0x208,0x127b0c,0x3dcc53) * 524 gdb RET ptrace -1 errno 14 Bad address 524 gdb CALL ptrace(PT_READ_I,0x208,0x127b0c,0) 524 gdb RET ptrace 4031315/0x3d8353 524 gdb CALL ptrace(PT_WRITE_D,0x208,0x127b0c,0x3dcc53) 524 gdb RET ptrace -1 errno 14 Bad address 524 gdb CALL ptrace(PT_WRITE_I,0x208,0x127b0c,0x3dcc53) 524 gdb RET ptrace -1 errno 14 Bad address 524 gdb CALL write(0x2,0xcb460,0x1c) 524 gdb GIO fd 2 wrote 28 bytes "Cannot insert breakpoint 1: " 524 gdb RET write 28/0x1c 524 gdb CALL write(0x1,0xe1000,0x36) 524 gdb GIO fd 1 wrote 54 bytes "Error accessing memory address 0x127b0d: Bad address. " The lines marked with (*) show the EFAULT (14) error. The address lies inside the emulator, but not in the VM86 area. Here is the map from /proc/PID/map (map is from doscmd, not gdb): 0x0 0x10000 7 0 rwx vnode 0x10000 0xe0000 11 0 rwx default 0xe0000 0xf0000 0 0 rwx none 0xf0000 0x100000 1 0 rwx default 0x100000 0x110000 14 0 rwx vnode 0x110000 0x1ef000 52 0 rwx default 0x8003000 0x8013000 13 0 r-x COW vnode 0x8013000 0x8015000 0 2 rwx COW vnode 0x8015000 0x801f000 0 10 rwx default 0x8020000 0x8023000 3 0 r-x COW vnode 0x8023000 0x8024000 0 1 rwx COW vnode 0x8024000 0x8089000 48 0 r-x COW vnode 0x8089000 0x808d000 0 4 rwx COW vnode 0x808d000 0x80a4000 0 9 rwx default 0xefbde000 0xefbfe000 1 4 rwx default As you can see, the area in question is mapped as default. The vnode entries from 0x0-0x10000 and 0x100000-0x110000 are the emulation of the memory wrap around (High memory area), the vnode from 0xe0000-0xf0000 is the (currently unmapped) EMS segment. The address requested by gdb is 0x127b0d and in range of 0x110000-0x1ef000. I checked the address in the symbol table, it is correct. It should work .. ? Any ideas ? Thank you Helmut -- Helmut F. Wirth Email: hfwirth@ping.at