From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3022 invoked by alias); 30 May 2009 23:18:00 -0000 Received: (qmail 3014 invoked by uid 22791); 30 May 2009 23:17:59 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 30 May 2009 23:17:52 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n4UNHmgT011080; Sat, 30 May 2009 19:17:48 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n4UNHlos012940; Sat, 30 May 2009 19:17:47 -0400 Received: from opsy.redhat.com (vpn-12-155.rdu.redhat.com [10.11.12.155]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n4UNHkdF016413; Sat, 30 May 2009 19:17:46 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 27FF23786E8; Sat, 30 May 2009 17:17:46 -0600 (MDT) To: Doug Evans Cc: gdb-patches@sourceware.org Subject: Re: RFC: next/finish/etc -vs- exceptions References: From: Tom Tromey Reply-To: Tom Tromey Date: Sat, 30 May 2009 23:18:00 -0000 In-Reply-To: (Doug Evans's message of "Sat\, 30 May 2009 14\:08\:21 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-05/txt/msg00657.txt.bz2 >>>>> "Doug" =3D=3D Doug Evans writes: Doug> Hi. My limited knowledge didn't find anything seriously broken 1/2 Doug> :-), but I do have a few comments. Thanks! Doug> To that end, should gdb print a warning if _Unwind_DebugHook isn't fo= und? Doug> Your patch isn't alone in this, and I'm not sure when and how to print Doug> such warnings. I wonder about this as well. Adding a warning in this case is a bit unusual, in that many programs do not use exceptions. E.g., getting this warning when debugging an ordinary C program would seem weird. Maybe there is some way around that. Doug> [To minimize the verbosity, gdb could print a general warning when it Doug> detects such conditions, with instructions on how to get further Doug> details. E.g. "GDB has detected conditions that will hinder some Doug> debugging efforts. Use `mumble' for further information." or some Doug> such. Yeah. We could add useful text in "help" somewhere. Maybe "help faq". Doug> That way the user might just get one warning at startup, and Doug> that's it. ... once per affected inferior, I think. Doug> The high order bit though is that there would be standard things the Doug> user can do to figure out why (e.g. in this case) "next" isn't working Doug> the way s/he is expecting it to (for typically frequent cases that are Doug> reasonable to handle - stripped libpthread anyone?). I like this idea. Tom> @@ -6356,6 +6403,7 @@ struct until_break_command_continuation_args Tom> =C2=A0{ Tom> =C2=A0 struct breakpoint *breakpoint; Tom> =C2=A0 struct breakpoint *breakpoint2; Tom> + =C2=A0int thread_num; Tom> =C2=A0}; Doug> Having to record the thread here seems orthogonal to handling next-ing Doug> over exceptions (e.g. why isn't it also required for longjmp?). IIRC, the longjmp code works for 'next' but not for 'until' (at least, my recollection is that longjmp does not work for all these commands; I don't remember exactly which ones). The reason this field is here is so that we can delete the exception breakpoint when cleaning up after the 'until'. The exception breakpoints are all thread-specific; recording the thread number is convenient since we already have delete_longjmp_breakpoint. Doug> Maybe add further comments explaining what's going on here? Will do. Tom> + =C2=A0 =C2=A0 =C2=A0/* We're going to replace the current step-resum= e breakpoint Tom> + =C2=A0 =C2=A0 =C2=A0 =C2=A0with a longjmp-resume breakpoint. =C2=A0*/ Doug> s/longjmp/exception/ ? Oops, thanks. Tom> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!SYMBOL_IS_ARGUMENT (sym)) Tom> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 continue; Doug> It's a bit odd to check function arguments for something like this. Doug> But maybe I just don't understand the implementation enough. Doug> There's an implementation aspect here that's not clear to me. Doug> Can you add comments elaborating on the argno =3D=3D 0 vs argno > 0 c= ases? I will add a comment. Meanwhile, here's the explanation. I added a function to the unwinder: /* This function is called during unwinding. It is intended as a hook for a debugger to intercept exceptions. CFA is the CFA of the target frame. HANDLER is the PC to which control will be transferred. */ static void _Unwind_DebugHook (void *cfa __attribute__ ((__unused__)), void *handler __attribute__ ((__unused__))) At 'next' time, gdb sets the "exception breakpoint" on this function. To use it, gdb then examines the arguments to the function. If the target frame, as represented by the CFA argument, is interesting (e.g., for 'next', somewhere in the current frame or above), then we set a temporary breakpoint at HANDLER. Doug> Blech. I haven't been paying attention to this myself. Doug> It's really nice to be able to add new testcases *without* having to Doug> edit any files like Makefile.in. Yes, I also am not a fan of this, or for that matter of the testsuite configure script and all the testsuite/*/Makefile.in files. I don't have an alternate proposal right now, though. Tom