This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] [PR 9514] Fixing parse error for "pointer to a function pointer"
- From: Abhijit Halder <abhijit dot k dot halder at gmail dot com>
- To: Keith Seitz <keiths at redhat dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, gdb-patches at sourceware dot org
- Date: Mon, 17 Oct 2011 16:29:01 +0530
- Subject: Re: [PATCH] [PR 9514] Fixing parse error for "pointer to a function pointer"
- References: <CAOhZP9yYEXV_rFEGQHPACeeYxiqAwYw4XjfNeozu18OWLFu24A@mail.gmail.com> <CAOhZP9yqbRXOd6rP2v1mpjszvRhycAOP9JwJXa+SQNz7tF5BRQ@mail.gmail.com> <201109291210.01022.pedro@codesourcery.com> <CAOhZP9xuEcQ97hb_DXK_ri0iR6pj_PDvtoJqCMPXMVpRcN+ZSg@mail.gmail.com> <m339fauipv.fsf@fleche.redhat.com> <4E8E18FC.4030705@redhat.com>
On Fri, Oct 7, 2011 at 2:39 AM, Keith Seitz <keiths@redhat.com> wrote:
> On 10/03/2011 09:45 AM, Tom Tromey wrote:
>>
>> Also, please look at my earlier patch for this bug. ?I think it shows
>> some cases that your patch does not address:
>>
>> ? ? http://sourceware.org/ml/gdb-patches/2008-08/msg00539.html
>>
>> Perhaps I ought to simply commit that patch. ?I am not sure why I never
>> have. ?What do you think?
>
> I've looked over both of these patches. Abhijit's original patch is much
> simpler, but there are still regressions using it w/CVS HEAD:
>
> +FAIL: gdb.base/code-expr.exp: (int ** @code)
> +FAIL: gdb.base/cvexpr.exp: (int ** const)
>
With latest CVS code the patch has no regression:
ahalder@ahalder-VirtualBox:~/Projects/gdb-enhanced/sandbox/src/gdb$
make check RUNTESTFLAGS=cvexpr.exp
make[1]: Entering directory
`/home/ahalder/Projects/gdb-enhanced/sandbox/src/gdb/testsuite'
Nothing to be done for all...
rootme=`pwd`; export rootme; srcdir=. ; export srcdir ; EXPECT=`if [
-f ${rootme}/../../expect/expect ] ; then echo
${rootme}/../../expect/expect ; else echo expect ; fi` ; export EXPECT
; EXEEXT= ; export EXEEXT ;
LD_LIBRARY_PATH=$rootme/../../expect:$rootme/../../libstdc++:$rootme/../../tk/unix:$rootme/../../tcl/unix:$rootme/../../bfd:$rootme/../../opcodes:$LD_LIBRARY_PATH;
export LD_LIBRARY_PATH; if [ -f ${rootme}/../../expect/expect ] ; then
TCL_LIBRARY=${srcdir}/../../tcl/library ; export TCL_LIBRARY ; fi ;
runtest cvexpr.exp
Test Run By ahalder on Mon Oct 17 14:48:12 2011
Native configuration is i686-pc-linux-gnu
=== gdb tests ===
Schedule of variations:
unix
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file
for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ./config/unix.exp as tool-and-target-specific interface file.
Running ./gdb.base/cvexpr.exp ...
=== gdb Summary ===
# of expected passes 115
/home/ahalder/Projects/gdb-enhanced/sandbox/src/gdb/testsuite/../../gdb/gdb
version 7.3.50.20111017-cvs -nw -nx -data-directory
/home/ahalder/Projects/gdb-enhanced/sandbox/src/gdb/testsuite/../data-directory
make[1]: Leaving directory
`/home/ahalder/Projects/gdb-enhanced/sandbox/src/gdb/testsuite'
ahalder@ahalder-VirtualBox:~/Projects/gdb-enhanced/sandbox/src/gdb$
make check RUNTESTFLAGS=code-expr.exp
make[1]: Entering directory
`/home/ahalder/Projects/gdb-enhanced/sandbox/src/gdb/testsuite'
Nothing to be done for all...
rootme=`pwd`; export rootme; srcdir=. ; export srcdir ; EXPECT=`if [
-f ${rootme}/../../expect/expect ] ; then echo
${rootme}/../../expect/expect ; else echo expect ; fi` ; export EXPECT
; EXEEXT= ; export EXEEXT ;
LD_LIBRARY_PATH=$rootme/../../expect:$rootme/../../libstdc++:$rootme/../../tk/unix:$rootme/../../tcl/unix:$rootme/../../bfd:$rootme/../../opcodes:$LD_LIBRARY_PATH;
export LD_LIBRARY_PATH; if [ -f ${rootme}/../../expect/expect ] ; then
TCL_LIBRARY=${srcdir}/../../tcl/library ; export TCL_LIBRARY ; fi ;
runtest code-expr.exp
Test Run By ahalder on Mon Oct 17 14:48:19 2011
Native configuration is i686-pc-linux-gnu
=== gdb tests ===
Schedule of variations:
unix
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file
for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ./config/unix.exp as tool-and-target-specific interface file.
Running ./gdb.base/code-expr.exp ...
=== gdb Summary ===
# of expected passes 101
/home/ahalder/Projects/gdb-enhanced/sandbox/src/gdb/testsuite/../../gdb/gdb
version 7.3.50.20111017-cvs -nw -nx -data-directory
/home/ahalder/Projects/gdb-enhanced/sandbox/src/gdb/testsuite/../data-directory
make[1]: Leaving directory
`/home/ahalder/Projects/gdb-enhanced/sandbox/src/gdb/testsuite'
ahalder@ahalder-VirtualBox:~/Projects/gdb-enhanced/sandbox/src/gdb$
------------------------------------------------------------------------------------------------------------------
ahalder@ahalder-VirtualBox:~/Projects/gdb-enhanced/sandbox/src/gdb$
cvsdiff c-exp.y
Index: c-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/c-exp.y,v
retrieving revision 1.84
diff -a -p -u -r1.84 c-exp.y
--- c-exp.y 11 Oct 2011 15:24:10 -0000 1.84
+++ c-exp.y 17 Oct 2011 10:58:06 -0000
@@ -942,6 +942,8 @@ const_or_volatile_or_space_identifier:
abs_decl: '*'
{ push_type (tp_pointer); $$ = 0; }
+ | abs_decl '*'
+ { push_type (tp_pointer); $$ = $1; }
| '*' abs_decl
{ push_type (tp_pointer); $$ = $2; }
| '&'
> I think Tom's approach is more generic, however more (marginally)
> complicated, but it, too, suffers from some problems. Most specifically, the
> ptr_operator production conflicts with the conversion operator production.
> Consider "ptype &foo::operator char* (void)" from cplusfuncs.exp.
>
> We end up in the "OPERATOR ptype" production, but because of the new
> ptr_operator rules, this is parsed as OPERATOR, nonempty_typelist, func_mod
> instead of OPERATOR, nonempty_typelist, '(', nonempty_typelist, ')'
>
> So we end up with "operator char (*" with Tom's patch. I keep thinking there
> must be a way to force the parser through the OPERATOR ptype production and
> then the TYPE_INSTANCE production, but I have not been successful. More
> savvy bison-ers might be able to do it, though. Or maybe I'll dedicate some
> time to this and figure it out.
>
> Maybe some crafty massaging of these three productions will yield a
> "simpler" answer.
>
> Keith
>