From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21992 invoked by alias); 10 Feb 2006 14:11:45 -0000 Received: (qmail 21982 invoked by uid 22791); 10 Feb 2006 14:11:44 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 10 Feb 2006 14:11:42 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1F7Yzq-0005lT-4g; Fri, 10 Feb 2006 09:11:38 -0500 Date: Fri, 10 Feb 2006 14:11:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Nick Roberts , gdb-patches@sourceware.org Subject: Re: minimalistic MI catch support Message-ID: <20060210141138.GA21506@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , Nick Roberts , gdb-patches@sourceware.org References: <17386.57501.980555.996896@kahikatea.snap.net.nz> <17388.13240.975679.344747@kahikatea.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00243.txt.bz2 On Fri, Feb 10, 2006 at 01:25:28PM +0200, Eli Zaretskii wrote: > > The second two have their own type: "catch fork" and "catch exec" (I must > > admit that I don't understand how this gives differerent behaviour from using > > "break fork" and "break exec"). They are associated with the system events reported for fork and exec. That means that in addition to the above, they'll catch things like clone with appropriate arguments, execlp, direct use of syscall()... Also, they give GDB external knowledge about what's going on, enabling it to track the child of the fork, or the target of the exec. That latter is currently disabled because the code and user interface for following exec were such a mess. > > Also for some reason, they have no address. Unlike a breakpoint, they are associated with an event and not an address. They aren't at all like breakpoints. > I think this is a bug (or undocumented misfeature) in > breakpoint.c:handle_gnu_v3_exceptions. You will see that it sets the > type of the raw breakpoint it creates to bp_breakpoint, instead of > using the argument ex_event that is passed by the caller. In > addition, for some reason, it forces a special function to be used for > printing these catchpoints, and that function > (print_one_exception_catchpoint) doesn't use the list of descriptions > in the bptypes[] array used by the more general code in > print_one_breakpoint. I think it's bad to have more than one place to > have these description strings. That's not a bug, it's supposed to be a progression! The idea was to, over time, make the breakpoint layer more object-oriented. Just because no one has had time to go back to it yet... One of my goals was to break up the huge switch statements on breakpoint type. ex_event is not suitable for two reasons; one is that EX_EVENT_CATCH has little direct relationship to the bp_* constants, and the other is that the type of the breakpoint is used to handle it, e.g. in bpstat_stop_status. "catch fork" is handled by a system event; on old HP systems, "catch throw" was too, which I suspect is why it was implemented as a catchpoint. But on GNU systems, EH catchpoints are just magical breakpoints in the runtime library. Ideally, after hitting them, we change frames a little ways up into the user's code; IIRC that's not implemented because of some problem I had getting it to work, but I can't remember the details. As background, the overall reason for making it more object oriented is the distinction between "what the user asked for" and "how gdb satisfies that request". For instance, a longstanding shortcoming in my humble opinion is that GDB can't use hardware breakpoint resources automatically - there's code that associates things like "bp_longjmp" with "oh, that's really a bp_breakpoint and I'll handle it like one", instead of information in the breakpoint that says "oh, this is really a software breakpoint". That's not 100% true any more now that I added bp->loc->loc_type, which explicitly says the breakpoint has type bp_loc_software_breakpoint. But the two are not yet fully decoupled. I'm not sure what "info breakpoints" should have to say about it; whether it should show the underlying implementation and address, or hide them as if it were a true catchpoint. If Nick's got a convincing argument to display "catchpoint" instead of "breakpoint", I'm sure we can change that. > Can someone explain why we should use special code for gnu_v3 > exceptions? I hope the above covers this. > As for the address not being printed, can you step with a debugger > through the function that prints these breakpoints and see why they > are skipped? I cannot for the moment see any reason, just looking at > the code. [Now we're talking about fork catchpoints rather than EH.] There's no meangingful address. See this in breakpoint.h: /* Note that zero is a perfectly valid code address on some platforms (for example, the mn10200 (OBSOLETE) and mn10300 simulators). NULL is not a special value for this field. Valid for all types except bp_loc_other. */ CORE_ADDR address; That's used for: - Software watchpoints. I still plan someday to finish refactoring this so that a single watchpoint, software or otherwise, has multiple bp_location entries, each with a valid address. But there will still be some software watchpoints that don't, e.g. I believe it is possible to set a software watchpoint on the value of a register. - Fork, vfork, and exec catchpoints. - Catch and throw catchpoints, if their type is bp_catch_*, which it is for the non-GNU implementation, which hasn't been tested in years. The last two are associated with system events, just like DLL events in Windows, not with a specific PC. -- Daniel Jacobowitz CodeSourcery