RE: [RFC] adding gdb.pascal subdir: updated version

["Pierre Muller" <muller at ics dot u-strasbg dot fr>]

  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@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] On Behalf Of 'Daniel Jacobowitz'
> Sent: Saturday, October 06, 2007 5:42 PM
> To: Pierre Muller
> Cc: gdb-patches@sourceware.org; gpc@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"