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' forexample) 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"
-
Pierre Muller