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

Pierre Muller
2007-10-08T07:14:32Z

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"