RE: [RFC-3] Handle GPC specific name for main function

["Pierre Muller" <muller@ics.u-strasbg.fr>]

> -----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