From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27746 invoked by alias); 27 Sep 2007 16:32:23 -0000 Received: (qmail 27737 invoked by uid 22791); 27 Sep 2007 16:32:22 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 27 Sep 2007 16:32:21 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 8943D2AAF58; Thu, 27 Sep 2007 12:32:19 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1cVQqMWL6E0o; Thu, 27 Sep 2007 12:32:19 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 51C6D2AAF49; Thu, 27 Sep 2007 12:32:19 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 2F9ECE7B58; Thu, 27 Sep 2007 09:32:17 -0700 (PDT) Date: Thu, 27 Sep 2007 16:32:00 -0000 From: Joel Brobecker To: Pierre Muller , 'Adriaan van Os' , gpc@gnu.de, gdb-patches@sourceware.org Subject: Re: [RFC-3] Handle GPC specific name for main function Message-ID: <20070927163217.GD3787@adacore.com> References: <000801c8008e$0aa12c70$1fe38550$@u-strasbg.fr> <20070927060246.GB3787@adacore.com> <000001c800d8$21cbcf00$65636d00$@u-strasbg.fr> <46FB5E2C.6080606@microbizz.nl> <46FB5F76.9050501@microbizz.nl> <000001c800dc$14b0df00$3e129d00$@u-strasbg.fr> <20070927121107.GB27706@caradoc.them.org> <001b01c80102$e371af60$aa550e20$@u-strasbg.fr> <20070927124020.GA29185@caradoc.them.org> <20070927162039.GC3787@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070927162039.GC3787@adacore.com> User-Agent: Mutt/1.4.2.2i 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: 2007-09/txt/msg00411.txt.bz2 > > > Anyhow, this can only lead to failures to detect > > > GPC properly. I think that the patch, even if it might > > > miss more cases, is also much more safe this way, because > > > we only use (_p_MO__main_program or pascal_main_program) > > > as start command breakpoint if '_p_initialize' was also found. > > > > Seems reasonable to me. Joel? > > Seems reasonable to me too. Actually, is it really reducing the potential for false positives? Let's recap: _p_initialize is defined when the Pascal runtime is linked in. _p_MO__main_program is sufficiently unlikely that such a symbol name should be a Pascal procedure pretty much all the time. So I'm wondering whether checking for _p_initialize will help reducing the number of false positive at all (because would _p_MO__main_program => _p_initialize). So is this patch really better than the previous one? -- Joel