This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Regression for gdb.pascal/* [Re: [RFA 4/4] Constify parse_linesepc]
- From: Sergio Durigan Junior <sergiodj at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: Keith Seitz <keiths at redhat dot com>, "gdb-patches\ at sourceware dot org ml" <gdb-patches at sourceware dot org>
- Date: Wed, 16 Oct 2013 19:07:08 -0300
- Subject: Re: Regression for gdb.pascal/* [Re: [RFA 4/4] Constify parse_linesepc]
- Authentication-results: sourceware.org; auth=none
- References: <5249C987 dot 50809 at redhat dot com> <87d2no4uim dot fsf at fleche dot redhat dot com> <524BA344 dot 2070802 at redhat dot com> <20131016095743 dot GA17072 at host2 dot jankratochvil dot net>
On Wednesday, October 16 2013, Jan Kratochvil wrote:
> On Wed, 02 Oct 2013 06:38:28 +0200, Keith Seitz wrote:
>> All committed. Thank you Sergio and Tom for looking at this!
>
> c85cddc51d5d9e4423509a2dc7cf3d9809451b49 is the first bad commit
> commit c85cddc51d5d9e4423509a2dc7cf3d9809451b49
> Author: Keith Seitz <keiths@redhat.com>
> Date: Wed Oct 2 00:46:06 2013 +0000
>
> Constification of parse_linespec and fallout:
> https://sourceware.org/ml/gdb-patches/2013-09/msg01017.html
> https://sourceware.org/ml/gdb-patches/2013-09/msg01018.html
> https://sourceware.org/ml/gdb-patches/2013-09/msg01019.html
> https://sourceware.org/ml/gdb-patches/2013-09/msg01020.html
Thanks for the report.
The problem happens because when yylex is going to parse a number, it
starts by saving the pointer to the input string in a variable "p", then
it advances this variable depending on what it finds, and finally it
updates "lexptr" by using "p". However, "p" is "tokstart" at the
beginning of the function, which used to be the same pointer as
"lexptr", but now it's allocated using "alloca".
I chose to fix this by advancing "p" and "lexptr" by the same amounts
every time, so that they do not get out of sync (which also makes it
unnecessary to update "lexptr" in the end).
I ran the failing tests and they pass now. I am running a regression
test now, but it will take a long time to complete, so I am sending this
patch for appreciation first.
OK to apply?
--
Sergio
gdb/
2013-10-16 Sergio Durigan Junior <sergiodj@redhat.com>
Fix regression by Keith's patch (Constification of parse_linesepc
and fallout).
* p-exp.y (yylex): Advance "lexptr" along with "p" when parsing a
number. Do not update "lexptr" using "p" in the end.
diff --git a/gdb/p-exp.y b/gdb/p-exp.y
index de14cbb..41628ea 100644
--- a/gdb/p-exp.y
+++ b/gdb/p-exp.y
@@ -1264,22 +1264,27 @@ yylex (void)
{
/* It's a number. */
int got_dot = 0, got_e = 0, toktype;
+ /* p and lexptr point to the same string, but not to the same
+ location. They should be both advanced at the same time
+ so that they do not get out of sync. */
char *p = tokstart;
int hex = input_radix > 10;
if (c == '0' && (p[1] == 'x' || p[1] == 'X'))
{
p += 2;
+ lexptr += 2;
hex = 1;
}
else if (c == '0' && (p[1]=='t' || p[1]=='T'
|| p[1]=='d' || p[1]=='D'))
{
p += 2;
+ lexptr += 2;
hex = 0;
}
- for (;; ++p)
+ for (;; ++p, ++lexptr)
{
/* This test includes !hex because 'e' is a valid hex digit
and thus does not indicate a floating point number when
@@ -1312,7 +1317,6 @@ yylex (void)
err_copy[p - tokstart] = 0;
error (_("Invalid number \"%s\"."), err_copy);
}
- lexptr = p;
return toktype;
}