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