Gpc

gpc@gnu.de

5400 discussions

Re: [RFC] adding gdb.pascal subdir: updated version
by Pierre Muller 08 Oct '07

08 Oct '07

This is the BIG problem about GDB pascal expression parser: - the single quotes are used in the C expression parser for these "quoted symbol reference", which I did not want to remove from the pascal expression parser, mainly because I did not really know what its use was, and I still don't know :(. Question to GPC people: does anyone use this "quoted symbol reference"? I thought that it could be very useful for overloaded functions (functions having the same name, but a diffent arg list, which is allowed in pascal). Thus I also left the double quote parsing as a string constant even though it is not the real pascal syntax. - but pascal strings are started by single quotes, not double quotes... I have a patch that would still search for quoted symbol reference, but would default to a pascal string in case nothing is found. The patch is rather simple, it just sets a variable named is_pascal_string, that is used if no symbol is found later to transform the character sequence into a real string. See diff below. The main problem is that doing this would give you subtle bugs like (gdb) pt 'Hello world' (gdb) type = array [0..11] of char (gdb) pt 'main' type = function .... Which is not really nice. I wanted to wait until the pascal subdirectory of the testsuite is added to start coping with this BIG problem... Index: p-exp.y =================================================================== RCS file: /cvs/src/src/gdb/p-exp.y,v retrieving revision 1.36 diff -u -p -r1.36 p-exp.y --- p-exp.y 3 Jul 2007 01:01:13 -0000 1.36 +++ p-exp.y 25 Sep 2007 15:52:23 -0000 @@ -1062,11 +1063,12 @@ yylex () int explen, tempbufindex; static char *tempbuf; static int tempbufsize; + int is_pascal_string; retry: prev_lexptr = lexptr; - + is_pascal_string = 0; tokstart = lexptr; explen = strlen (lexptr); /* See if it is a special token of length 3. */ @@ -1129,6 +1131,7 @@ yylex () error ("Unmatched single quote."); namelen -= 2; tokstart++; + is_pascal_string = 1; uptokstart = uptok(tokstart,namelen); goto tryname; } @@ -1648,6 +1651,16 @@ yylex () /* Any other kind of symbol */ yylval.ssym.sym = sym; yylval.ssym.is_a_field_of_this = is_a_field_of_this; + if (!sym && is_pascal_string) + { + /* Handle this as a normal pascal string. */ + tempbuf = (char *) realloc (tempbuf, namelen + 1); + strncpy (tempbuf, tokstart, namelen); + tempbuf[namelen] = '\0'; + yylval.sval.ptr = tempbuf; + yylval.sval.length = namelen; + return (STRING); + } return NAME; } } > -----Original Message----- > From: gdb-patches-owner(a)sourceware.org [mailto:gdb-patches- > owner(a)sourceware.org] On Behalf Of 'Daniel Jacobowitz' > Sent: Saturday, October 06, 2007 5:42 PM > To: Pierre Muller > Cc: gdb-patches(a)sourceware.org; gpc(a)gnu.de > Subject: Re: [RFC] adding gdb.pascal subdir: updated version > > On Sat, Sep 08, 2007 at 12:38:47AM +0200, Pierre Muller wrote: > > +proc test_string_literal_types_accepted {} { > > + global gdb_prompt > > + > > + # Test various character values. > > + > > + gdb_test "pt 'a simple string'" "type = string" > > +} > > Pierre, is this the correct Pascal syntax for a string or not? > > We have: > > case '\'': > /* We either have a character constant ('0' or '\177' for > example) > or we have a quoted symbol reference ('foo(int,int)' in object > pascal > for example). */ > > and there is a separate case for double-quoted strings. > > Resolving that question will take care of one failure for both fpc and > gpc. The other two GPC failures should be handled like in the patch > I've attached. The failure at "start" is a GDB bug, so we label that > a KFAIL ("known failure"). The shouldn't be committed with gdb/NNNN > still in it. It should either have a bug number in our bug database, > or else just wait until the patch to fix it is checked in. > > The other test is definitely a bug in GPC. I read through the DWARF > dump and there is no reference to line 10, so GDB will never display > it. So that's an XFAIL, an expected failure due to our environment. > It needs to get a little more complicated if the GPC bug is fixed > some day, using gdb_test_multiple. > > -- > Daniel Jacobowitz > CodeSourcery > > diff -u gdb.pascal/hello.exp gdb.pascal/hello.exp > --- gdb.pascal/hello.exp 7 Sep 2007 21:46:31 -0000 > +++ gdb.pascal/hello.exp 6 Oct 2007 15:39:32 -0000 > @@ -50,6 +50,9 @@ > # This test fails for gpc > # because debug information for 'main' > # is in some <implicit code> > +if { $pascal_compiler_is_gpc } { > + setup_kfail *-*-* gdb/NNNN > +} > gdb_test "" \ > ".* at .*hello.pas.*" \ > "start" > @@ -64,6 +67,9 @@ > # This test also fails for gpc because the program > # stops after the string has been written > # while it should stop before writing it > +if { $pascal_compiler_is_gpc } { > + setup_xfail *-*-* > +} > gdb_test "cont" \ > "Breakpoint .*:${bp_location2}.*" \ > "Going to second breakpoint"

1 0

Mod operator issue
by Adriaan van Os 04 Oct '07

04 Oct '07

The following two programs fail on i386-apple-darwin when using gpc version 20051116 with gcc-3.4.5, but not when using gpc version 20070904 with gcc-4.1.2. This was reported by Stéphane Nicolet on the mac-pascal mailiong list. Does someone remember if this is a back-end or front-end problem ? {$mac-pascal} program modbug; var a,b: integer; c: boolean; begin a := 22; b := 12; c:= ((a - 15) mod b) = (b-1) end. {$borland-pascal} program modbug; var a,b: integer; c: boolean; begin a := 22; b := 12; c:= ((a - 15) mod b) = (b-1) end. Regards, Adriaan van Os

3 2

[RFA] Handle GPC specific name for main function
by Pierre Muller 03 Oct '07

03 Oct '07

This is my final patch to be able to detect the fact that GPC was used to compile the main procedure and set the name of that main procedure (which is either "pascal_main_program" or "_p__M0_main_program"). The whole thread started with http://sourceware.org/ml/gdb-patches/2007-09/msg00373.html Is it OK to commit? Pierre Muller Pascal language maintainer. ChangeLog entry: 2007-10-03 Pierre Muller <muller(a)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. 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 3 Oct 2007 09:21:58 -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 3 Oct 2007 09:21:58 -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 3 Oct 2007 09:21:59 -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.939 diff -u -p -r1.939 Makefile.in --- Makefile.in 27 Sep 2007 18:48:32 -0000 1.939 +++ Makefile.in 3 Oct 2007 09:22:00 -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) \

1 0

gpc issue with some record structure
by Peter Schorn 02 Oct '07

02 Oct '07

I did some further investigations on the gpc issue I recently discovered on Mac OS X 10.4.10 PowerPC (gpc 20070904, based on gcc-4.1.2). The following program exhibits the problem: program schorn3; type abc = record a, b, c: Extended; end; const d = 22092007.192016; procedure outer; var x: abc; procedure inner(p: abc); begin if x.a = d then writeln('OK') else writeln('Fail. Got x.a = ', x.a, '. Expected x.a =', d); end; begin { outer } x.a := d; inner(x); end; begin outer; end. The following behavior is observed: peter% /Developer/Pascal/gpc412/bin/gpc -o schorn3 schorn3.pas peter% schorn3 Fail. Got x.a = -3.066700750256657e-231. Expected x.a = 2.209200719201600e+07 Now with --pack-struct (although it seems there is nothing to pack) peter% /Developer/Pascal/gpc412/bin/gpc --pack-struct -o schorn3 schorn3.pas peter% schorn3 OK The previous test program for this issue caused bus errors or segmentation faults on Macintoshes but also had a chance to succeed by chance (only a boolean at a possibly wrong address was tested). Maybe the issue now shows up on other platforms as well. Peter ----- peter.schorn at acm.org

5 7

Re: [RFC-3] Handle GPC specific name for main function
by Pierre Muller 27 Sep '07

27 Sep '07

> -----Original Message----- > From: Joel Brobecker [mailto:brobecker@adacore.com] > Sent: Thursday, September 27, 2007 6:32 PM > To: Pierre Muller; 'Adriaan van Os'; gpc(a)gnu.de; gdb- > patches(a)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

1 0

[RFC-3] Handle GPC specific name for main function
by Pierre Muller 27 Sep '07

27 Sep '07

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

3 5

Re: [RFC-3] Handle GPC specific name for main function
by Pierre Muller 27 Sep '07

27 Sep '07

> -----Original Message----- > From: gdb-patches-owner(a)sourceware.org [mailto:gdb-patches- > owner(a)sourceware.org] On Behalf Of Daniel Jacobowitz > Sent: Thursday, September 27, 2007 2:11 PM > To: Pierre Muller > Cc: 'Adriaan van Os'; gpc(a)gnu.de; gdb-patches(a)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

1 0

[RFC] Handle GPC specific name for main function
by Pierre Muller 27 Sep '07

27 Sep '07

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(a)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");

2 1

Re: [RFC] Handle GPC specific name for main function
by Pierre Muller 26 Sep '07

26 Sep '07

> 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

1 1

Re: [RFC] Handle GPC specific name for main function
by Pierre Muller 26 Sep '07

26 Sep '07

> -----Original Message----- > From: Joel Brobecker [mailto:brobecker@adacore.com] > Sent: Wednesday, September 26, 2007 7:58 PM > To: Pierre Muller > Cc: gdb-patches(a)sourceware.org; gpc(a)gnu.de > Subject: Re: [RFC] Handle GPC specific name for main function > > Hello Pierre, > > > 2007-09-26 Pierre Muller <muller(a)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

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc