Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!uunet!elroy.jpl.nasa.gov!usc!venice!gumby.dsd.trw.com!eel.dsd.trw.com!gottloeb
From: gottloeb@eel.dsd.trw.com (Jeffrey R. Gottloeb)
Subject: Re: GDB under 386bsd 0.1
Message-ID: <1992Sep8.163904.8941@gumby.dsd.trw.com>
Keywords: gdb, ptrace
Sender: news@gumby.dsd.trw.com
Organization: TRW, INC.
References: <1992Sep4.005417.3876@gumby.dsd.trw.com> <1992Sep4.153554.4387@cs.few.eur.nl>
Date: Tue, 8 Sep 1992 16:39:04 GMT
Lines: 44
In article <1992Sep4.153554.4387@cs.few.eur.nl> pk@cs.eur.nl writes:
>In <1992Sep4.005417.3876@gumby.dsd.trw.com> gottloeb@eel.dsd.trw.com writes:
>
>>I have noticed a problem using gdb under 386bsd 0.1.
>
>>When at least one breakpoint has been set and the program terminates,
>>e.g. executes exit(), the breakpoint is not removed from the process's
>>text image. When the program is subsequently re-executed under gdb,
>>gdb remembers that a breakpoint is supposed to at the memory location
>>and puts one there again. However this time it shadows the breakpoint
>>instruction from the previous run rather than the original instruction.
>>When execution begins after reaching the breakpoint, various traps occur.
>
>>If the program is run after quitting gdb, a Trace/BPT trap occurs.
>
>>I think the problem is that gdb assumes that when ptrace modifies the
>>process's image the kernel either makes a private copy of the text image
>>or it will throw away the text image after the process terminates.
>>However, this is not the case - the kernel keeps the modified text image
>>around and executes it rather than a fresh copy from the original file.
>
>The 386 does not generate a page protection fault while it is executing
>in supervisor mode :-(, so copy on write handling never takes place when
>the kernel stuffs data into a process's text- or any other non-anonymous
>segment. So these cases must be explicitly checked for. Here's a patch
>for kern/sys_process.c:
>
>
(code deleted)
>
>I am not entirely happy about the call to `vm_fault', but at this moment
>I don't see another way to enforce a copy on write.
>
>-pk
I modified kern/sys_process.c with the patch and rebuilt the kernel.
This fixed the problem. Thanks.
Jeff Gottloeb
gottloeb@gumby.dsd.trw.com