[RFC-3] Handle GPC specific name for main function
muller at ics.u-strasbg.fr
Thu Sep 27 23:36:43 CEST 2007
> -----Original Message-----
> From: Joel Brobecker [mailto:brobecker at adacore.com]
> Sent: Thursday, September 27, 2007 6:32 PM
> To: Pierre Muller; 'Adriaan van Os'; gpc at gnu.de; gdb-
> patches at 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
> 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 =>
> So is this patch really better than the previous one?
Yes, because it was not simply '_p__M0_main_program'
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.
More information about the Gpc