From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20190 invoked by alias); 27 Sep 2007 21:36:52 -0000 Received: (qmail 20180 invoked by uid 22791); 27 Sep 2007 21:36:52 -0000 X-Spam-Check-By: sourceware.org Received: from ics.u-strasbg.fr (HELO ics.u-strasbg.fr) (130.79.112.250) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 27 Sep 2007 21:36:49 +0000 Received: from ICSMULLER (unknown [130.79.244.149]) by ics.u-strasbg.fr (Postfix) with ESMTP id 5A86418701D; Thu, 27 Sep 2007 23:41:40 +0200 (CEST) From: "Pierre Muller" To: "'Joel Brobecker'" , "'Adriaan van Os'" , , 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> <20070927163217.GD3787@adacore.com> In-Reply-To: <20070927163217.GD3787@adacore.com> Subject: RE: [RFC-3] Handle GPC specific name for main function Date: Thu, 27 Sep 2007 21:36:00 -0000 Message-ID: <000601c8014e$7f7c2b60$7e748220$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us 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/msg00418.txt.bz2 > -----Original Message----- > From: Joel Brobecker [mailto:brobecker@adacore.com] > Sent: Thursday, September 27, 2007 6:32 PM > To: Pierre Muller; 'Adriaan van Os'; gpc@gnu.de; gdb- > patches@sourceware.org > Subject: Re: [RFC-3] Handle GPC specific name for main function > > > > > 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? Yes, because it was not simply '_p__M0_main_program' but basically: if msym('_p_M0_main_program') exists, return '_p__M0_main_program' else if sym('pascal_main_program') exist, return 'pascal_main_program' else return NIL. The old name is more usual, and could be generated by any compiler (its even a valid C function name, if if there is not underscore prepended!). To avoid false positives on the second version mainly, it is better. We could decide to do the check of '_p_initialize' only for that second case; that would probably reduce the number of recent GPC compilation misses. Pierre Muller