[RFC] Handle GPC specific name for main function

[RFC] Handle GPC specific name for main function

[Pierre Muller]

  This patch looks up for
GPC specific minimal symbols
and assumes that if they are present,
the executable was compiled by GPC.
  GPC used 'pascal_main_program' and now
uses '_p__M0_main_program'.

  Is there some other way to check that the 
program was really compiled by GPC?
(Any C compiled program could have a
'pascal_main_program' function...)

  Maybe by looking up some other symbol?
I found 'GPC_init' as a possible candidate,
but I am not sure that this symbol is 
defined for all versions of GPC, so I did not 
include it in the present RFC.

  I tested the patch on Cygwin and it
allows to use 'start' command and get
directly at the right location.

  This will also help to reduce the gap between
GPC and FreePascal for the (not yet committed)
gdb.pascal testsuite directory.

  Any feedback from GPC users would be most helpful here.

Pierre Muller
Pascal language maintainer.



ChangeLog entry:

2007-09-26  Pierre Muller  <muller@ics.u-strasbg.fr>
	* p-lang.h (pascal_main_name): New function.
	p-lang.c (GPC_MAIN_PROGRAM_NAME_1,
	GPC_MAIN_PROGRAM_NAME_2): New char array constants
	corresponding to the two minimal symbols used 
	by GPC compiler.
	(pascal_main_name): Try to find minimal symbol
	corresponding to the entry of GPC compiled programs.
	symtab.c (find_main_name): Try to find
	pascal specific main name by calling pascal_main_name.



$ cvs diff -up p-lang.h p-lang.c symtab.c
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    26 Sep 2007 14:26:08 -0000
@@ -21,6 +21,8 @@

 struct value;

+extern char *pascal_main_name (void);
+
 extern int pascal_parse (void);        /* 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    26 Sep 2007 14:26:09 -0000
@@ -35,6 +35,43 @@
 extern void _initialize_pascal_language (void);


+/* The name of the symbol used by GPC compiler.  */
+
+static const char GPC_MAIN_PROGRAM_NAME_1[]
+  = "pascal_main_program";
+static const char GPC_MAIN_PROGRAM_NAME_2[]
+  = "_p__M0_main_program";
+
+char *
+pascal_main_name (void)
+{
+  struct minimal_symbol *msym;
+  CORE_ADDR main_program_name_addr;
+  static char main_program_name[1024];
+
+  /* For GPC, main procedure s a special name.
+     .  */
+
+
+  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;
+    }
+
+  /* The main procedure doesn't seem to be in GPC.
+     Thus default "main" should work.  */
+  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    26 Sep 2007 14:26:10 -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");

Re: [RFC] Handle GPC specific name for main function

[Eli Zaretskii]

> From: "Pierre Muller" <muller@ics.u-strasbg.fr>
> Cc: <gpc@gnu.de>
> Date: Wed, 26 Sep 2007 16:40:30 +0200
> 
> +  /* For GPC, main procedure s a special name.
> +     .  */

What happened here? this comment is not formatted according to GNU
coding style.

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

[Pierre Muller]

Sorry, 
  Could you please point me again to the 
right place for comment formatting?
  I remember that single line is different from
multi-line, and that multi-line comments
should end with a point and two spaces before the closing '*/'
 
http://www.gnu.org/prep/standards/
does not seem very explicit about this,
unless I did not find the right place inside...

 Concerning the comment below,
should it be
1)  /* For GPC, main procedure has a special name */
2)  /*  For GPC, main procedure has a special name.  */
or something else?

Pierre

> -----Original Message-----
> From: Eli Zaretskii [mailto:eliz@gnu.org]
> Sent: Wednesday, September 26, 2007 5:04 PM
> To: Pierre Muller
> Cc: gdb-patches@sourceware.org; gpc@gnu.de
> Subject: Re: [RFC] Handle GPC specific name for main function
> 
> > From: "Pierre Muller" <muller@ics.u-strasbg.fr>
> > Cc: <gpc@gnu.de>
> > Date: Wed, 26 Sep 2007 16:40:30 +0200
> >
> > +  /* For GPC, main procedure s a special name.
> > +     .  */
> 
> What happened here? this comment is not formatted according to GNU
> coding style.

Re: [RFC] Handle GPC specific name for main function

[Eli Zaretskii]

> From: "Pierre Muller" <muller@ics.u-strasbg.fr>
> Cc: <gdb-patches@sourceware.org>,
> 	<gpc@gnu.de>
> Date: Wed, 26 Sep 2007 17:32:23 +0200
> 
> Sorry, 
>   Could you please point me again to the 
> right place for comment formatting?

That would be the node "Comments" in standards.info.

>   I remember that single line is different from
> multi-line, and that multi-line comments
> should end with a point and two spaces before the closing '*/'

Right.  But in the fragment on which I commented there was an extra
period and a spurious newline before it.

>  Concerning the comment below,
> should it be
> 1)  /* For GPC, main procedure has a special name */
> 2)  /*  For GPC, main procedure has a special name.  */
> or something else?

The second variant is correct.

Re: [RFC] Handle GPC specific name for main function

[Joel Brobecker]

Hello Pierre,

> 2007-09-26  Pierre Muller  <muller@ics.u-strasbg.fr>
> 	* p-lang.h (pascal_main_name): New function.
> 	p-lang.c (GPC_MAIN_PROGRAM_NAME_1,
> 	GPC_MAIN_PROGRAM_NAME_2): New char array constants
> 	corresponding to the two minimal symbols used 
> 	by GPC compiler.
> 	(pascal_main_name): Try to find minimal symbol
> 	corresponding to the entry of GPC compiled programs.
> 	symtab.c (find_main_name): Try to find
> 	pascal specific main name by calling pascal_main_name.

This is mostly OK, except for the tiny comment formatting pointed out
by Eli. I have a few suggestions:

> +/* The name of the symbol used by GPC compiler.  */

I find this is too vague. I suggest something like:

  /* The name of the symbol that GPC uses as the name of the main
     subprogram.  There are several possibilities depending on
     the version of GPC.  */

I might even go one step further and put a comment for each entry.
Something like:

  /* The name of the symbol that GPC uses as the name of the main
     subprogram (since version ...).  */

And then, for the other one say:

  /* Older versions of GPC (version ... and older) were using
     a different name for the main subprogram.  */

> +static const char GPC_MAIN_PROGRAM_NAME_1[]
> +  = "pascal_main_program";
> +static const char GPC_MAIN_PROGRAM_NAME_2[]
> +  = "_p__M0_main_program";

Also, I think you might want to order them the opposite way.
The net effect is that you'll end up trying the newer symbol
first, and then fallback to the older symbol. When people
start using the newer compiler, GDB will need to do only one
symbol lookup to find a match.

> +  /* For GPC, main procedure s a special name.
> +     .  */

I think making the comment above a bit more expressive makes
this comment superfluous.

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

You also need to update Makefile.in, since you added a dependency.

With these adjustments in, your patch is pre-approved (but please
remember to give it a round of testing, just in cases).

Thank you,
-- 
Joel

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

[Pierre Muller]

> -----Original Message-----
> From: Joel Brobecker [mailto:brobecker@adacore.com]
> Sent: Wednesday, September 26, 2007 7:58 PM
> To: Pierre Muller
> Cc: gdb-patches@sourceware.org; gpc@gnu.de
> Subject: Re: [RFC] Handle GPC specific name for main function
> 
> Hello Pierre,
> 
> > 2007-09-26  Pierre Muller  <muller@ics.u-strasbg.fr>
> > 	* p-lang.h (pascal_main_name): New function.
> > 	p-lang.c (GPC_MAIN_PROGRAM_NAME_1,
> > 	GPC_MAIN_PROGRAM_NAME_2): New char array constants
> > 	corresponding to the two minimal symbols used
> > 	by GPC compiler.
> > 	(pascal_main_name): Try to find minimal symbol
> > 	corresponding to the entry of GPC compiled programs.
> > 	symtab.c (find_main_name): Try to find
> > 	pascal specific main name by calling pascal_main_name.
> 
> This is mostly OK, except for the tiny comment formatting pointed out
> by Eli. I have a few suggestions:
> 
> > +/* The name of the symbol used by GPC compiler.  */
> 
> I find this is too vague. I suggest something like:
> 
>   /* The name of the symbol that GPC uses as the name of the main
>      subprogram.  There are several possibilities depending on
>      the version of GPC.  */
> 
> I might even go one step further and put a comment for each entry.
> Something like:
> 
>   /* The name of the symbol that GPC uses as the name of the main
>      subprogram (since version ...).  */

  Here, I really need feedback from GPC developers!
 
> And then, for the other one say:
> 
>   /* Older versions of GPC (version ... and older) were using
>      a different name for the main subprogram.  */
> 
> > +static const char GPC_MAIN_PROGRAM_NAME_1[]
> > +  = "pascal_main_program";
> > +static const char GPC_MAIN_PROGRAM_NAME_2[]
> > +  = "_p__M0_main_program";
> 
> Also, I think you might want to order them the opposite way.
> The net effect is that you'll end up trying the newer symbol
> first, and then fallback to the older symbol. When people
> start using the newer compiler, GDB will need to do only one
> symbol lookup to find a match.

  You are perfectly right, chances are higher that
the program will be compiled by a recent or future
GPC.

> > +  /* For GPC, main procedure s a special name.
> > +     .  */
> 
> I think making the comment above a bit more expressive makes
> this comment superfluous.
> 
> > @@ -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"
> >
> 
> You also need to update Makefile.in, since you added a dependency.

  Funny, while trying to add this, I noticed that
${ada_lang_h} was twice in the dependency list, so
I just replaced the second one with ${p_lang_h}
 
> With these adjustments in, your patch is pre-approved (but please
> remember to give it a round of testing, just in cases).

  Thanks, but my problem is that I am unable to run the testsuite,
and anyhow gdb.pascal is not yet in CVS,
and its mainly there where I expect a change.
 
Pierre

Re: [RFC] Handle GPC specific name for main function

[Joel Brobecker]

> >   /* The name of the symbol that GPC uses as the name of the main
> >      subprogram (since version ...).  */
> 
>   Here, I really need feedback from GPC developers!

This makes sense. I thought you had already consulted with the GPC
developers...

> > You also need to update Makefile.in, since you added a dependency.
> 
>   Funny, while trying to add this, I noticed that
> ${ada_lang_h} was twice in the dependency list, so
> I just replaced the second one with ${p_lang_h}

Excellent, thanks for catching and fixing this.

> > With these adjustments in, your patch is pre-approved (but please
> > remember to give it a round of testing, just in cases).
> 
>   Thanks, but my problem is that I am unable to run the testsuite,
> and anyhow gdb.pascal is not yet in CVS,
> and its mainly there where I expect a change.

I am mostly concerned about the effect on the other languages.
I just want to make sure that the rest of the testsuite results
stay unchanged. If you don't have access to a machine where you
can run the testsuite, then let me know, and I'll give it a quick
run on one of our fast machines for you. Your change looks relatively
straightforward, but it never hurts to be cautious.

-- 
Joel

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

[Pierre Muller]

> I am mostly concerned about the effect on the other languages.
> I just want to make sure that the rest of the testsuite results
> stay unchanged. If you don't have access to a machine where you
> can run the testsuite, then let me know, and I'll give it a quick
> run on one of our fast machines for you. Your change looks relatively
> straightforward, but it never hurts to be cautious.
> 

I finally ran the testsuite
on Ubuntu (inside VMWare)

  The outcome is a bit better after the patch,
but I do NOT understand how this patch
could have any influence on 'help' behavior.
  Thus I suspect that this
is just non-reproducable...

Pierre

gdb.sum.before is for a clean CVS,
gdb.sum is after applying the patch.

fpc@ubuntu:/usr/local/src/build/gdb/testsuite$ diff gdb.sum.before gdb.sum
1c1
< Test Run By fpc on Wed Sep 26 22:41:20 2007
---
> Test Run By fpc on Wed Sep 26 23:37:23 2007
3056,3060c3056,3060
< FAIL: gdb.base/help.exp: help clear (timeout)
< FAIL: gdb.base/help.exp: help commands
< FAIL: gdb.base/help.exp: help condition
< FAIL: gdb.base/help.exp: help core-file
< FAIL: gdb.base/help.exp: help delete "d" abbreviation 
---
> PASS: gdb.base/help.exp: help clear
> PASS: gdb.base/help.exp: help commands
> PASS: gdb.base/help.exp: help condition
> PASS: gdb.base/help.exp: help core-file
> PASS: gdb.base/help.exp: help delete "d" abbreviation 
11129,11130c11129,11130
< # of expected passes          10489
< # of unexpected failures      38
---
> # of expected passes          10494
> # of unexpected failures      33

[RFC-2] Handle GPC specific name for main function

[Pierre Muller]

  I updated my patch according to the comments from
Eli and Joel. Thanks to both.
 
  Eli, I added a comment in p-lang.c
that is not really conform to standards, but 
the whole file uses similar comments.
Should I reformat them? In a separate patch?

  To GPC developers:
   there is a blank in the patch:
Joel proposed to tell up to which version of
GPC, the old name was used.
  I have no idea about that, could someone
please tell me.
  By the way, is there some publically
readable CVS tree for GPC sources?

  As stated in a previous email, the patch
does not seem to generate new failures
in the testsuite.

Pierre

ChangeLog entry:

2007-09-26  Pierre Muller  <muller@ics.u-strasbg.fr>

        * p-lang.h (pascal_main_name): New function.
        p-lang.c (GPC_MAIN_PROGRAM_NAME_1),
        (GPC_MAIN_PROGRAM_NAME_2): New char array constants
        corresponding to the two 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    26 Sep 2007 22:30:59 -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    26 Sep 2007 22:31:00 -0000
@@ -35,6 +35,43 @@
 extern void _initialize_pascal_language (void);


+/* The name of the symbol that GPC uses as the name of the main
+   subprogram (since version ...).  */
+static const char GPC_MAIN_PROGRAM_NAME_1[]
+  = "_p__M0_main_program";
+
+/* Older versions of GPC (version ... and older) were using
+   a different name for the main subprogram.  */
+static const char GPC_MAIN_PROGRAM_NAME_2[]
+  = "pascal_main_program";
+
+/* Function returning the special symbol name used
+   by GPC if it is found in minimal symbol list.  */
+
+char *
+pascal_main_name (void)
+{
+  struct minimal_symbol *msym;
+
+  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;
+    }
+
+/*  The main procedure doesn't seem to be compiled with GPC.
+    Thus default name "main" should work.  */
+  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    26 Sep 2007 22:31:02 -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 26 Sep 2007 22:31:04 -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)
\

Re: [RFC] Handle GPC specific name for main function

[Waldek Hebisch]

Pierre Muller wrote:
>   This patch looks up for
> GPC specific minimal symbols
> and assumes that if they are present,
> the executable was compiled by GPC.
>   GPC used 'pascal_main_program' and now
> uses '_p__M0_main_program'.
> 
>   Is there some other way to check that the 
> program was really compiled by GPC?
> (Any C compiled program could have a
> 'pascal_main_program' function...)
> 
>   Maybe by looking up some other symbol?
> I found 'GPC_init' as a possible candidate,
> but I am not sure that this symbol is 
> defined for all versions of GPC, so I did not 
> include it in the present RFC.
> 

I doubt that any simple method will work for "all versions of GPC".
According to change log  'pascal_main_program' was introduced
24 Jun 2000, earler GPC used 'program_Foo' where 'Foo' is program name.
'_p__M0_main_program' appeared in gpc-20050217 (however, there for
a few month the change was available as a patch, so '_p__M0_main_program'
may appear also in earlier versions).

I would say that the most reliable indication that the program 
is GPC compiled is if debug info indicate that language is Pascal
and there are signs that the file is gcc compiled (otherwise the file
is compiled by some other Pascal compiler).  If debug info indicate
other language file is not GPC compiled.  

Concerning 'GPC_init':  it is probably present in all currently
used versions.  It is absent in ancient versions like gpc-1.2-2.7.2.
'GPC_init' may vanish from future versions -- it is one of few
names in GPC runtime which do not use '_p_' prefix.  Also, while
I know of no way to omit 'GPC_init' when using standard runtime
it is possible to use alternative runtime which does not contain
'GPC_init.

When checking if program is GPC compiled one may look at 
'_p_initialize' -- it is present at least from 1993 up to now.
Also current GPC versions use a special symbol to check for
matched runtiome.  This symbol looks like '_p_GPC_RTS_VERSION_20060215'
(where to last part encodes version of the runtime).  Versions
before 2004-02-04 used GPC_RTS_VERSION_YYYYMMDD.  I do not know
when this symbol was introduced -- it is absent in gpc-1.2-2.7.2
but present in gpc-20020510.  Both '_p_initialize' and
'_p_GPC_RTS_VERSION_20060215' are referenced from 'main', so
they must appear even if alternate runtime is in use.

GPC emits '_p__M0_main_program' (or 'pascal_main_program')
in the same file as 'main', and '_p__M0_main_program' is called
from 'main' -- I am not sure if gdb can check this.

Let me remark that it is possible to have '_p__M0_main_program'
without having 'main'.  Namely,  GPC allows to compile Pascal source
like normal program, but replacing main by a differently named function.
One use of such possibility is when making shared libraries.  Another 
is when the main program is not a Pascal program.

-- 
                              Waldek Hebisch
hebisch@math.uni.wroc.pl 

Re: [RFC] Handle GPC specific name for main function

[Joel Brobecker]

Thanks a lot for the detailed explainations.

> I doubt that any simple method will work for "all versions of GPC".

It doesn't have to. We can add support for as many or as few
versions of GPC.

> I would say that the most reliable indication that the program 
> is GPC compiled is if debug info indicate that language is Pascal
> and there are signs that the file is gcc compiled (otherwise the file
> is compiled by some other Pascal compiler).  If debug info indicate
> other language file is not GPC compiled.  

Unfortunately, we have to consider multi-language applications too.
Verifying that one file is compiled with GPC is not enough to determine
that the main is in Pascal.

> GPC emits '_p__M0_main_program' (or 'pascal_main_program')
> in the same file as 'main', and '_p__M0_main_program' is called
> from 'main' -- I am not sure if gdb can check this.

This is a possibility, but will only work if we have debugging
info.

> Let me remark that it is possible to have '_p__M0_main_program'
> without having 'main'.  Namely,  GPC allows to compile Pascal source
> like normal program, but replacing main by a differently named function.
> One use of such possibility is when making shared libraries.  Another 
> is when the main program is not a Pascal program.

That's a big throwback, because it means that Pierre's patch is not
correct, in particular in the context of multi-language applications.
It was assuming that this symbol was only defined when the main program
is in pascal.

It looks like we're reaching the same conclusion as before, which is
that, unless GPC gets changed to emit a specific symbol to specify
that the main is in pascal, the strongest approach is to rely on
DWARF data. 

http://www.cygwin.com/ml/gdb-patches/2005-11/msg00380.html

-- 
Joel

Re: [RFC-2] Handle GPC specific name for main function

[Joel Brobecker]

Pierre,

> 2007-09-26  Pierre Muller  <muller@ics.u-strasbg.fr>
> 
>         * p-lang.h (pascal_main_name): New function.
>         p-lang.c (GPC_MAIN_PROGRAM_NAME_1),
>         (GPC_MAIN_PROGRAM_NAME_2): New char array constants
>         corresponding to the two 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.

Based on the new information that we received, and if I understood
it correctly, it looks like we were operating on the wrong assumption,
which makes this patch actually wrong. I should say "less correct".

This will work fine for programs written exclusively in Pascal,
and multi-language programs where the main in Pascal. However,
there is a chance that this patch makes GDB incorrectly determine
the main to be a Pascal procedure when in fact it is not. I'm not sure
about the ratio of the better behavior vs the incorrect one.

Maybe it is one of these patches that may improve the situation 75%
of the time, while introducing a bug the rest of the time.  So maybe
the GDB maintainers as a group will find that it is still fine to still
include your patch as a pragmatic compromise. But I can no longer give
it the OK on my own. I personally don't have a strong opinion, but I'm
slightly leaning against it. I would prefer us to start designing a
better way now.

-- 
Joel

Re: [RFC-2] Handle GPC specific name for main function

[Eli Zaretskii]

> From: "Pierre Muller" <muller@ics.u-strasbg.fr>
> Cc: <gdb-patches@sourceware.org>,
> 	<gpc@gnu.de>
> Date: Thu, 27 Sep 2007 00:39:03 +0200
> 
>   Eli, I added a comment in p-lang.c
> that is not really conform to standards, but 
> the whole file uses similar comments.
> Should I reformat them? In a separate patch?

Yes, please.

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

[Pierre Muller]

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

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

[Pierre Muller]

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

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

[Pierre Muller]

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

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

[Daniel Jacobowitz]

On Thu, Sep 27, 2007 at 09:57:41AM +0200, Pierre Muller wrote:
> > 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.

Yes, it matters.  libgpc will not be loaded yet, so _p_initialize
might be missing when we try to find the main function.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Pierre Muller]

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] On Behalf Of Daniel Jacobowitz
> Sent: Thursday, September 27, 2007 2:11 PM
> To: Pierre Muller
> Cc: 'Adriaan van Os'; gpc@gnu.de; gdb-patches@sourceware.org
> Subject: Re: [RFC-3] Handle GPC specific name for main function
> 
> On Thu, Sep 27, 2007 at 09:57:41AM +0200, Pierre Muller wrote:
> > > 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.
> 
> Yes, it matters.  libgpc will not be loaded yet, so _p_initialize
> might be missing when we try to find the main function.

  Would then looking after __imp_p_initialize
find something?
  You need to excuse me, but I have no
idea of the library loading works...

  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.

Pierre

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

['Daniel Jacobowitz']

On Thu, Sep 27, 2007 at 02:35:29PM +0200, Pierre Muller wrote:
>   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?

-- 
Daniel Jacobowitz
CodeSourcery

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

[Waldek Hebisch]

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.

-- 
                              Waldek Hebisch
hebisch@math.uni.wroc.pl 

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

[Joel Brobecker]

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

-- 
Joel

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

[Joel Brobecker]

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

-- 
Joel

Re: [RFC] Handle GPC specific name for main function

[Thiago Jung Bauermann]

On Wed, 2007-09-26 at 22:52 -0700, Joel Brobecker wrote:
> It looks like we're reaching the same conclusion as before, which is
> that, unless GPC gets changed to emit a specific symbol to specify
> that the main is in pascal, the strongest approach is to rely on
> DWARF data. 
> 
> http://www.cygwin.com/ml/gdb-patches/2005-11/msg00380.html

Unfortunately, from the discussion above there is no adequate DWARF tag
to specify which is the main program. Like Dan Berlin suggested, it is
necessary to come up with a new one and make the compilers (gpc and
gfortran) emit those.
-- 
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center

Re: [RFC] Handle GPC specific name for main function

[Jim Blandy]

Thiago Jung Bauermann <bauerman@br.ibm.com> writes:
> On Wed, 2007-09-26 at 22:52 -0700, Joel Brobecker wrote:
>> It looks like we're reaching the same conclusion as before, which is
>> that, unless GPC gets changed to emit a specific symbol to specify
>> that the main is in pascal, the strongest approach is to rely on
>> DWARF data. 
>> 
>> http://www.cygwin.com/ml/gdb-patches/2005-11/msg00380.html
>
> Unfortunately, from the discussion above there is no adequate DWARF tag
> to specify which is the main program. Like Dan Berlin suggested, it is
> necessary to come up with a new one and make the compilers (gpc and
> gfortran) emit those.

The DWARF committee discussed adding a tag to do this, but it got
bogged down in questions about what to do in cases like Java and Ada
and COBOL, and how to phrase the definition to mean the right thing in
all those cases.  If the DWARF web site is up to date, the proposal
got sent back for revision.

http://dwarfstd.org/ShowIssue.php?issue=070619.1&type=open

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

[Pierre Muller]

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

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

[Joel Brobecker]

>   To avoid false positives on the second version mainly,
> it is better.

Right, that makes sense indeed. For some reason, I thought that
the second symbol name was "MAIN__", not "pascal_main_program".
I was confused. I still agree with Daniel that the current patch
is quite reasonable.

If "pascal_main_program" ends up being a problem in practic, we have
the option of stop supporting GPC version older than 20070217, when
it was replaced by '_p__M0_main_program' (more than 2 years ago,
now).

-- 
Joel