Based on comments from Waldek and concerns from Joel, I propose that we first check for the presence of the '_p_initialize' minimal symbol, and only look for '_p_M0_main_program' and 'pascal_main_program' if the '_p_initialize' was found.
This should reduce substantially the risks of false catches. Joel, does this seem enough for you, or should we really insist on checking if the program was compiled by gcc, like Waldek also suggested, but which would mean that only programs having debug information present would get a chance of being detected correctly, while the present patch also works for programs without debugging information.
Pierre Muller
ChangeLog entry: 2007-09-27 Pierre Muller muller@ics.u-strasbg.fr
* p-lang.h (pascal_main_name): New function. p-lang.c (GPC_P_INITIALIZE, GPC_MAIN_PROGRAM_NAME_1), (GPC_MAIN_PROGRAM_NAME_2): New char array constants corresponding to the three minimal symbols used by GPC compiler. (pascal_main_name): Try to find minimal symbol corresponding to the entry of GPC compiled programs. symtab.c: New include p-lang.h. (find_main_name): Try to find pascal specific main name by calling pascal_main_name. * Makefile.in (symtab.o): Add dependency on p-lang header.
$ cvs diff -up p-lang.h p-lang.c symtab.c Makefile.in Index: p-lang.h =================================================================== RCS file: /cvs/src/src/gdb/p-lang.h,v retrieving revision 1.12 diff -u -p -r1.12 p-lang.h --- p-lang.h 23 Aug 2007 18:08:36 -0000 1.12 +++ p-lang.h 27 Sep 2007 07:20:00 -0000 @@ -21,6 +21,9 @@
struct value;
+/* Defined in p-lang.c */ +extern char *pascal_main_name (void); + extern int pascal_parse (void); /* Defined in p-exp.y */
extern void pascal_error (char *); /* Defined in p-exp.y */ Index: p-lang.c =================================================================== RCS file: /cvs/src/src/gdb/p-lang.c,v retrieving revision 1.33 diff -u -p -r1.33 p-lang.c --- p-lang.c 23 Sep 2007 16:25:05 -0000 1.33 +++ p-lang.c 27 Sep 2007 07:20:00 -0000 @@ -35,6 +35,63 @@ extern void _initialize_pascal_language (void);
+/* All GPC versions until now (2007-09-27) also define a symbol called + '_p_initialize'. Check for the presence of this symbol first. */ + static const char GPC_P_INITIALIZE[] + = "_p_initialize"; + +/* The name of the symbol that GPC uses as the name of the main + procedure (since version 20050212). */ +static const char GPC_MAIN_PROGRAM_NAME_1[] + = "_p__M0_main_program"; + +/* Older versions of GPC (versions older than 20050212) were using + a different name for the main procedure. */ +static const char GPC_MAIN_PROGRAM_NAME_2[] + = "pascal_main_program"; + +/* Function returning the special symbol name used + by GPC for the main procedure in the main program + if it is found in minimal symbol list. + This function tries to find minimal symbols generated by GPC + so that it finds the even if the program was compiled + without debugging information. + According to information supplied by Waldeck Hebisch, + this should work for all versions posterior to June 2000. */ + +char * +pascal_main_name (void) +{ + struct minimal_symbol *msym; + + msym = lookup_minimal_symbol (GPC_P_INITIALIZE, NULL, NULL); + + /* If '_p_initialize' was not found, + the program doesn't seem to be compiled with GPC. + Thus default name "main" should work. */ + if (msym == NULL) + return NULL; + + msym = lookup_minimal_symbol (GPC_MAIN_PROGRAM_NAME_1, NULL, NULL); + + if (msym != NULL) + { + return (char *)GPC_MAIN_PROGRAM_NAME_1; + } + + msym = lookup_minimal_symbol (GPC_MAIN_PROGRAM_NAME_2, NULL, NULL); + + if (msym != NULL) + { + return (char *)GPC_MAIN_PROGRAM_NAME_2; + } + +/* No known entry procedure found, use default 'main' name. + According to Waldek Hebish, this should not happen for any GPC version + after June 2000 and up to 2007-09-27. */ + return NULL; +} + /* Determines if type TYPE is a pascal string type. Returns 1 if the type is a known pascal type This function is used by p-valprint.c code to allow better string display. Index: symtab.c =================================================================== RCS file: /cvs/src/src/gdb/symtab.c,v retrieving revision 1.165 diff -u -p -r1.165 symtab.c --- symtab.c 24 Sep 2007 07:40:32 -0000 1.165 +++ symtab.c 27 Sep 2007 07:20:01 -0000 @@ -40,6 +40,7 @@ #include "filenames.h" /* for FILENAME_CMP */ #include "objc-lang.h" #include "ada-lang.h" +#include "p-lang.h"
#include "hashtab.h"
@@ -4151,6 +4152,13 @@ find_main_name (void) return; }
+ new_main_name = pascal_main_name (); + if (new_main_name != NULL) + { + set_main_name (new_main_name); + return; + } + /* The languages above didn't identify the name of the main procedure. Fallback to "main". */ set_main_name ("main"); Index: Makefile.in =================================================================== RCS file: /cvs/src/src/gdb/Makefile.in,v retrieving revision 1.938 diff -u -p -r1.938 Makefile.in --- Makefile.in 17 Sep 2007 19:32:53 -0000 1.938 +++ Makefile.in 27 Sep 2007 07:20:02 -0000 @@ -2751,7 +2751,7 @@ symtab.o: symtab.c $(defs_h) $(symtab_h) $(filenames_h) $(objc_lang_h) $(ada_lang_h) $(hashtab_h) \ $(gdb_obstack_h) $(block_h) $(dictionary_h) $(gdb_string_h) \ $(gdb_stat_h) $(cp_abi_h) $(observer_h) $(gdb_assert_h) \ - $(solist_h) $(ada_lang_h) + $(solist_h) $(p_lang_h) target.o: target.c $(defs_h) $(gdb_string_h) $(target_h) $(gdbcmd_h) \ $(symtab_h) $(inferior_h) $(bfd_h) $(symfile_h) $(objfiles_h) \ $(gdb_wait_h) $(dcache_h) $(regcache_h) $(gdb_assert_h) $(gdbcore_h) \
Pierre Muller wrote:
Based on comments from Waldek and concerns from Joel, I propose that we first check for the presence of the '_p_initialize' minimal symbol, and only look for '_p_M0_main_program' and 'pascal_main_program' if the '_p_initialize' was found.
The check should certainly not be for _p_M0_main_program or pascal_main_program'. Waldek rightly remarked that e.g. shared libraries won't have these symbols. Better is to look for _p_initialize and/or GPC_RTS_VERSION_YYYYMMDD.
This should reduce substantially the risks of false catches. Joel, does this seem enough for you, or should we really insist on checking if the program was compiled by gcc, like Waldek also suggested, but which would mean that only programs having debug information present would get a chance of being detected correctly, while the present patch also works for programs without debugging information.
For compatibility with some bintools even FPC emits 'gcc2_compiled' (on Linux, I believe).
Regards,
Adriaan van Os
Pierre Muller wrote:
Based on comments from Waldek and concerns from Joel, I propose that we first check for the presence of the '_p_initialize' minimal symbol, and only look for '_p_M0_main_program' and 'pascal_main_program' if the '_p_initialize' was found.
The check should certainly not be for _p_M0_main_program or pascal_main_program'. Waldek rightly remarked that e.g. shared libraries won't have these symbols. Better is to look for _p_initialize and/or GPC_RTS_VERSION_YYYYMMDD.
On second thought - are these symbols present when linking to a dynamic libgpc ?
Regards,
Adriaan van Os
-----Original Message----- From: gpc-owner@gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Adriaan van Os Sent: Thursday, September 27, 2007 9:45 AM To: gpc@gnu.de Subject: Re: [RFC-3] Handle GPC specific name for main function
Pierre Muller wrote:
Based on comments from Waldek and concerns from Joel, I propose that we first check for the presence of the '_p_initialize' minimal symbol, and only look for '_p_M0_main_program' and 'pascal_main_program' if the '_p_initialize' was found.
The check should certainly not be for _p_M0_main_program or pascal_main_program'. Waldek rightly remarked that e.g. shared
libraries
won't have these symbols. Better is to look for _p_initialize and/or GPC_RTS_VERSION_YYYYMMDD.
On second thought - are these symbols present when linking to a dynamic libgpc ?
Does this matter anyhow? We are just trying to get the gdb command 'start' to end up at the right location, i.e. for a pascal program, at the start of the main procedure of the main source.
This is of no meaning for a library, unless I am missing something... I doubt that you can use 'start' for a library.
Pierre
-----Original Message----- From: gpc-owner@gnu.de [mailto:gpc-owner@gnu.de] On Behalf Of Adriaan van
Os
Sent: Thursday, September 27, 2007 9:39 AM To: gpc@gnu.de Subject: Re: [RFC-3] Handle GPC specific name for main function
Pierre Muller wrote:
Based on comments from Waldek and concerns from Joel, I propose that we first check for the presence of the '_p_initialize' minimal symbol, and only look for '_p_M0_main_program' and 'pascal_main_program' if the '_p_initialize' was found.
The check should certainly not be for _p_M0_main_program or pascal_main_program'. Waldek rightly remarked that e.g. shared libraries won't have these symbols. Better is to look for _p_initialize and/or GPC_RTS_VERSION_YYYYMMDD.
As stated in my other email, the whole purpose of this patch is not to determine if the source was compiled by GPC, but to get the command 'start' to end up at the right location. This right location is either '_p_M0_main_program' or 'pascal_main_program' (or 'program_Foo' for very old version, that my patch will not support.)
This should reduce substantially the risks of false catches. Joel, does this seem enough for you, or should we really insist on checking if the program was compiled by gcc, like Waldek also suggested, but which would mean that only programs having debug information present would get a chance of being detected correctly, while the present patch also works for programs without debugging information.
For compatibility with some bintools even FPC emits 'gcc2_compiled' (on Linux, I believe).
Meaning that this is not a good way to distinguish between GPC and Free Pascal anyhow.
Pierre
Pierre Muller wrote:
As stated in my other email, the whole purpose of this patch is not to determine if the source was compiled by GPC, but to get the command 'start' to end up at the right location. This right location is either '_p_M0_main_program' or 'pascal_main_program' (or 'program_Foo' for very old version, that my patch will not support.)
Assuming that the main program is compiled by GPC looking for '_p_M0_main_program' or 'pascal_main_program' should work fine. However, if the main program was compiled by some other compiler the program in principle may still contain such magic symbol -- using it as start location would be wrong.
In the 'demos' subdirectory of gpc tarball one can find files 'gpc_c_pas.pas', 'gpc_c_unit.pas' and 'gpc_c_c.c' -- this is a demo program showing how to make main program in C but use from it Pascal routines. In this example '_p_M0_main_program' is never called and the right location for 'start' command is C main. It is easy to create mixed mode program without fake '_p_M0_main_program', but unfortunately the demo creates fake '_p_M0_main_program'.
Another possibility is program in other language (or compiled by some other Pascal compiler) which happens to contain 'pascal_main_program'. I hope that '_p_M0_main_program' is very unlikely to appear in non-GPC program, but 'pascal_main_program' is a reasonable name so it makes sense to look for confirmation that the program is GPC compiled.
'_p_initialize' indicates presence of GPC runtime (so it really does not help in case of mixed mode programs). I should also mention that there was a report that 'libplot' library also contains '_p_initialize' function...
I also mentioned shared libraries. Now I think that they pose no extra problem -- presumably 'start' command will go to a symbol in main executable and just ignore shared libraries.
-
Adriaan van Os -
Pierre Muller -
Waldek Hebisch