From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31696 invoked by alias); 24 Jul 2009 17:25:51 -0000 Received: (qmail 31672 invoked by uid 22791); 24 Jul 2009 17:25:51 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 24 Jul 2009 17:25:45 +0000 Received: (qmail 11273 invoked from network); 24 Jul 2009 17:25:42 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 24 Jul 2009 17:25:42 -0000 From: Pedro Alves To: gdb-patches@sourceware.org, Tom Tromey Subject: Re: RFC: next/finish/etc -vs- exceptions Date: Fri, 24 Jul 2009 18:54:00 -0000 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200907241825.41764.pedro@codesourcery.com> X-IsSubscribed: yes 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-07/txt/msg00602.txt.bz2 On Friday 24 July 2009 17:54:50, Tom Tromey wrote: > I also haven't yet tried to make the longjmp code work like the > exception code. =A0I'd like to see Pedro's glibc/longjmp fix go in first, > so I can have a reasonable chance of testing any changes here. Sorry, I took a deeper look at your previous patch a few weeks ago over a weekend, but then the weekend ran out before I finished the review, and then I stayed quiet about it waiting for some other time to finish what I had started, but that never arrived. :-/ I already had patches to do something like like you mention to the longjmp code from 2008, but I hadn't re-posted them because of the glibc pointer mangling getting in the way. I found out that your code to detect if the exception is outer or not won't always work for longjmps, in the longjmp tests I have for example. This made me wonder if we shouldn't get longjmp done first, and then maybe reuse it or not for exceptions if it makes sense. As it is in your patch, you're reusing the longjmp paths in infrun.c and co., but it may end up that's not a good choice. I also thought at the time that there were some things in that patch (I didn't look at this new one yet), that should be split into independent changes, like changes to insert longjmp breakpoints in a few commands that didn't had them inserted (but memory is a bit vague by now though, I can't remember exact details). I did brush up my only-follow-longjmp-if-going-outer patches a bit and I was aiming at posting it before you had updated your patch, but obviously I failed. :-/ I think if we have a chance of looking at what needs addressing for longjmp first (and split your changes that concern with longjmp too), we will have a better result. Would you mind that? I'll try to get at it again this weekend, and post what I have, and finish up the review I had already started (looking at the new patch, of course). --=20 Pedro Alves