* [PATCH] Recognize and skip interpreter_p initialization in selftest.exp
@ 2006-02-26 18:40 Fred Fish
2006-02-26 18:49 ` Daniel Jacobowitz
0 siblings, 1 reply; 5+ messages in thread
From: Fred Fish @ 2006-02-26 18:40 UTC (permalink / raw)
To: gdb-patches; +Cc: fnf
With the latest development gcc and latest development gdb,
selftest.exp fails because the breakpoint at captured_main gets set at
the interpreter_p initialization, which isn't currently one of the
recognized patterns. Apparently optimization has gotten better and
this code has been moved up the instruction stream:
(gdb) br captured_main
Breakpoint 1 at 0x807c714: file /src/latest/trunk/src/gdb/gdb/main.c, line 241.
(gdb) run
Starting program: /links/build/latest/trunk/i686-pc-linux-gnu/gdb/gdb/gdb
Breakpoint 1, captured_main (data=0xbfdbb3f4) at /src/latest/trunk/src/gdb/gdb/main.c:241
241 interpreter_p = xstrdup (context->interpreter_p);
-Fred
2006-02-26 Fred Fish <fnf@specifix.com>
* gdb.gdb/selftest.exp (do_steps_and_nexts): Recognize
and skip over interpreter_p initialization.
Index: testsuite/gdb.gdb/selftest.exp
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/testsuite/gdb.gdb/selftest.exp,v
retrieving revision 1.1.1.2
diff -c -p -r1.1.1.2 selftest.exp
*** testsuite/gdb.gdb/selftest.exp 30 Dec 2005 18:53:28 -0000 1.1.1.2
--- testsuite/gdb.gdb/selftest.exp 26 Feb 2006 18:27:34 -0000
*************** proc do_steps_and_nexts {} {
*** 184,189 ****
--- 184,193 ----
set description "next over getcwd"
set command "next"
}
+ -re ".*interpreter_p = xstrdup.*$gdb_prompt $" {
+ set description "next over interpreter_p initialization"
+ set command "next"
+ }
-re "\[ \t\]+\{\r\n$gdb_prompt $" {
setup_xfail "mips-*-irix5*"
fail "$description ended up at odd location"
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Recognize and skip interpreter_p initialization in selftest.exp
2006-02-26 18:40 [PATCH] Recognize and skip interpreter_p initialization in selftest.exp Fred Fish
@ 2006-02-26 18:49 ` Daniel Jacobowitz
2006-02-26 19:38 ` Fred Fish
0 siblings, 1 reply; 5+ messages in thread
From: Daniel Jacobowitz @ 2006-02-26 18:49 UTC (permalink / raw)
To: Fred Fish; +Cc: gdb-patches
On Sun, Feb 26, 2006 at 01:35:28PM -0500, Fred Fish wrote:
> With the latest development gcc and latest development gdb,
> selftest.exp fails because the breakpoint at captured_main gets set at
> the interpreter_p initialization, which isn't currently one of the
> recognized patterns. Apparently optimization has gotten better and
> this code has been moved up the instruction stream:
>
> (gdb) br captured_main
> Breakpoint 1 at 0x807c714: file /src/latest/trunk/src/gdb/gdb/main.c, line 241.
> (gdb) run
> Starting program: /links/build/latest/trunk/i686-pc-linux-gnu/gdb/gdb/gdb
> Breakpoint 1, captured_main (data=0xbfdbb3f4) at /src/latest/trunk/src/gdb/gdb/main.c:241
> 241 interpreter_p = xstrdup (context->interpreter_p);
I'm not sure "better" is the word I'd use - how the heck did that
happen? Could you please verify a couple of things for me: that we are
reasonably close to the beginning of the function, that the prologue
skipper hasn't gone too far, and that the instruction being executed
has actually got some relationship to line 241.
I've noticed some strange failures in this test recently too, but I
haven't had time to look into them. It's entirely possible that
nothing's wrong and your patch is fine - I'm just being paranoid for
GCC and/or GDB bugs.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Recognize and skip interpreter_p initialization in selftest.exp
2006-02-26 18:49 ` Daniel Jacobowitz
@ 2006-02-26 19:38 ` Fred Fish
2006-02-26 20:23 ` Mark Kettenis
0 siblings, 1 reply; 5+ messages in thread
From: Fred Fish @ 2006-02-26 19:38 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb-patches
On Sunday 26 February 2006 13:40, Daniel Jacobowitz wrote:
> happen? Could you please verify a couple of things for me: that we are
> reasonably close to the beginning of the function, that the prologue
> skipper hasn't gone too far, and that the instruction being executed
> has actually got some relationship to line 241.
I'm not very familiar with x86 assembly so I'm probably not the best one
to look closely at the code generated for captured_main.
Here is what I get when I run by hand and do a bunch of "next" commands:
(gdb) br captured_main
Breakpoint 1 at 0x807c714: file /src/latest/trunk/src/gdb/gdb/main.c, line 241.
(gdb) run
Starting program: /links/build/latest/trunk/i686-pc-linux-gnu/gdb/gdb/gdb
Breakpoint 1, captured_main (data=0xbfbb4734) at /src/latest/trunk/src/gdb/gdb/main.c:241
241 interpreter_p = xstrdup (context->interpreter_p);
(gdb) next
120 {
(gdb)
241 interpreter_p = xstrdup (context->interpreter_p);
(gdb)
120 {
(gdb)
123 char **argv = context->argv;
(gdb)
122 int argc = context->argc;
(gdb)
123 char **argv = context->argv;
(gdb)
122 int argc = context->argc;
(gdb)
165 long time_at_startup = get_run_time ();
(gdb)
168 setlocale (LC_MESSAGES, "");
(gdb)
165 long time_at_startup = get_run_time ();
(gdb)
168 setlocale (LC_MESSAGES, "");
(gdb)
171 setlocale (LC_CTYPE, "");
(gdb)
173 bindtextdomain (PACKAGE, LOCALEDIR);
(gdb)
174 textdomain (PACKAGE);
(gdb)
177 lim_at_start = (char *) sbrk (0);
(gdb)
187 cmdarg = (struct cmdarg *) xmalloc (cmdsize * sizeof (*cmdarg));
(gdb)
177 lim_at_start = (char *) sbrk (0);
(gdb)
I suppose it's possible though that the code at 0x807c714 doesn't have anything to
do with line 241:
(gdb) x/40i captured_main
0x807c710 <captured_main>: push %ebp
0x807c711 <captured_main+1>: mov %esp,%ebp
0x807c713 <captured_main+3>: push %edi
0x807c714 <captured_main+4>: mov $0x1,%edi
0x807c719 <captured_main+9>: push %esi
0x807c71a <captured_main+10>: mov $0x1,%esi
0x807c71f <captured_main+15>: push %ebx
0x807c720 <captured_main+16>: sub $0x11c,%esp
0x807c726 <captured_main+22>: mov 0x8(%ebp),%ebx
0x807c729 <captured_main+25>: mov 0x4(%ebx),%edx
0x807c72c <captured_main+28>: mov (%ebx),%eax
0x807c72e <captured_main+30>: mov %edx,0xffffff08(%ebp)
0x807c734 <captured_main+36>: mov %eax,0xffffff04(%ebp)
0x807c73a <captured_main+42>: call 0x8230970 <get_run_time>
0x807c73f <captured_main+47>: movl $0x823b767,0x4(%esp)
0x807c747 <captured_main+55>: movl $0x5,(%esp)
0x807c74e <captured_main+62>: mov %eax,0xffffff30(%ebp)
0x807c754 <captured_main+68>: call 0x807ba20 <setlocale@plt>
0x807c759 <captured_main+73>: movl $0x823b767,0x4(%esp)
0x807c761 <captured_main+81>: movl $0x0,(%esp)
0x807c768 <captured_main+88>: call 0x807ba20 <setlocale@plt>
0x807c76d <captured_main+93>: movl $0x8232b80,0x4(%esp)
0x807c775 <captured_main+101>: movl $0x8232a90,(%esp)
0x807c77c <captured_main+108>: call 0x807bd20 <bindtextdomain@plt>
0x807c781 <captured_main+113>: movl $0x8232a90,(%esp)
0x807c788 <captured_main+120>: call 0x807c030 <textdomain@plt>
0x807c78d <captured_main+125>: movl $0x0,(%esp)
0x807c794 <captured_main+132>: call 0x807be10 <sbrk@plt>
0x807c799 <captured_main+137>: movl $0x8,(%esp)
0x807c7a0 <captured_main+144>: mov %eax,0x82d36e0
0x807c7a5 <captured_main+149>: call 0x8084f20 <xmalloc>
0x807c7aa <captured_main+154>: movl $0x4,(%esp)
0x807c7b1 <captured_main+161>: mov %eax,0xffffff20(%ebp)
0x807c7b7 <captured_main+167>: call 0x8084f20 <xmalloc>
0x807c7bc <captured_main+172>: movl $0x0,0x82d3b90
0x807c7c6 <captured_main+182>: mov %eax,0xffffff28(%ebp)
0x807c7cc <captured_main+188>: mov 0x82b0d68,%eax
0x807c7d1 <captured_main+193>: mov %eax,(%esp)
0x807c7d4 <captured_main+196>: call 0x8084f20 <xmalloc>
0x807c7d9 <captured_main+201>: mov %eax,0x82d36fc
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Recognize and skip interpreter_p initialization in selftest.exp
2006-02-26 19:38 ` Fred Fish
@ 2006-02-26 20:23 ` Mark Kettenis
2006-02-26 22:44 ` Daniel Jacobowitz
0 siblings, 1 reply; 5+ messages in thread
From: Mark Kettenis @ 2006-02-26 20:23 UTC (permalink / raw)
To: fnf; +Cc: drow, gdb-patches
> From: Fred Fish <fnf@specifix.com>
> Date: Sun, 26 Feb 2006 14:11:48 -0500
>
> On Sunday 26 February 2006 13:40, Daniel Jacobowitz wrote:
> > happen? Could you please verify a couple of things for me: that we are
> > reasonably close to the beginning of the function, that the prologue
> > skipper hasn't gone too far, and that the instruction being executed
> > has actually got some relationship to line 241.
>
> I'm not very familiar with x86 assembly so I'm probably not the best one
> to look closely at the code generated for captured_main.
The mov $0x1,%edi is probably initializing a local variable to 1. It
is very unlikely that this instruction is part of line 241; it's much
more likely this is line 186 or 189. I'd say, that GCC is generating
bogus line number information or GDB is interpreting that line number
information uncorrectly. Either way, your "fix" is probably papering
over a real bug.
> Here is what I get when I run by hand and do a bunch of "next" commands:
>
> (gdb) br captured_main
> Breakpoint 1 at 0x807c714: file /src/latest/trunk/src/gdb/gdb/main.c, line 241.
> (gdb) run
> Starting program: /links/build/latest/trunk/i686-pc-linux-gnu/gdb/gdb/gdb
> Breakpoint 1, captured_main (data=0xbfbb4734) at /src/latest/trunk/src/gdb/gdb/main.c:241
> 241 interpreter_p = xstrdup (context->interpreter_p);
> (gdb) next
> 120 {
> (gdb)
> 241 interpreter_p = xstrdup (context->interpreter_p);
> (gdb)
> 120 {
> (gdb)
> 123 char **argv = context->argv;
> (gdb)
> 122 int argc = context->argc;
> (gdb)
> 123 char **argv = context->argv;
> (gdb)
> 122 int argc = context->argc;
> (gdb)
> 165 long time_at_startup = get_run_time ();
> (gdb)
> 168 setlocale (LC_MESSAGES, "");
> (gdb)
> 165 long time_at_startup = get_run_time ();
> (gdb)
> 168 setlocale (LC_MESSAGES, "");
> (gdb)
> 171 setlocale (LC_CTYPE, "");
> (gdb)
> 173 bindtextdomain (PACKAGE, LOCALEDIR);
> (gdb)
> 174 textdomain (PACKAGE);
> (gdb)
> 177 lim_at_start = (char *) sbrk (0);
> (gdb)
> 187 cmdarg = (struct cmdarg *) xmalloc (cmdsize * sizeof (*cmdarg));
> (gdb)
> 177 lim_at_start = (char *) sbrk (0);
> (gdb)
>
>
> I suppose it's possible though that the code at 0x807c714 doesn't have anything to
> do with line 241:
>
> (gdb) x/40i captured_main
> 0x807c710 <captured_main>: push %ebp
> 0x807c711 <captured_main+1>: mov %esp,%ebp
> 0x807c713 <captured_main+3>: push %edi
> 0x807c714 <captured_main+4>: mov $0x1,%edi
> 0x807c719 <captured_main+9>: push %esi
> 0x807c71a <captured_main+10>: mov $0x1,%esi
> 0x807c71f <captured_main+15>: push %ebx
> 0x807c720 <captured_main+16>: sub $0x11c,%esp
> 0x807c726 <captured_main+22>: mov 0x8(%ebp),%ebx
> 0x807c729 <captured_main+25>: mov 0x4(%ebx),%edx
> 0x807c72c <captured_main+28>: mov (%ebx),%eax
> 0x807c72e <captured_main+30>: mov %edx,0xffffff08(%ebp)
> 0x807c734 <captured_main+36>: mov %eax,0xffffff04(%ebp)
> 0x807c73a <captured_main+42>: call 0x8230970 <get_run_time>
> 0x807c73f <captured_main+47>: movl $0x823b767,0x4(%esp)
> 0x807c747 <captured_main+55>: movl $0x5,(%esp)
> 0x807c74e <captured_main+62>: mov %eax,0xffffff30(%ebp)
> 0x807c754 <captured_main+68>: call 0x807ba20 <setlocale@plt>
> 0x807c759 <captured_main+73>: movl $0x823b767,0x4(%esp)
> 0x807c761 <captured_main+81>: movl $0x0,(%esp)
> 0x807c768 <captured_main+88>: call 0x807ba20 <setlocale@plt>
> 0x807c76d <captured_main+93>: movl $0x8232b80,0x4(%esp)
> 0x807c775 <captured_main+101>: movl $0x8232a90,(%esp)
> 0x807c77c <captured_main+108>: call 0x807bd20 <bindtextdomain@plt>
> 0x807c781 <captured_main+113>: movl $0x8232a90,(%esp)
> 0x807c788 <captured_main+120>: call 0x807c030 <textdomain@plt>
> 0x807c78d <captured_main+125>: movl $0x0,(%esp)
> 0x807c794 <captured_main+132>: call 0x807be10 <sbrk@plt>
> 0x807c799 <captured_main+137>: movl $0x8,(%esp)
> 0x807c7a0 <captured_main+144>: mov %eax,0x82d36e0
> 0x807c7a5 <captured_main+149>: call 0x8084f20 <xmalloc>
> 0x807c7aa <captured_main+154>: movl $0x4,(%esp)
> 0x807c7b1 <captured_main+161>: mov %eax,0xffffff20(%ebp)
> 0x807c7b7 <captured_main+167>: call 0x8084f20 <xmalloc>
> 0x807c7bc <captured_main+172>: movl $0x0,0x82d3b90
> 0x807c7c6 <captured_main+182>: mov %eax,0xffffff28(%ebp)
> 0x807c7cc <captured_main+188>: mov 0x82b0d68,%eax
> 0x807c7d1 <captured_main+193>: mov %eax,(%esp)
> 0x807c7d4 <captured_main+196>: call 0x8084f20 <xmalloc>
> 0x807c7d9 <captured_main+201>: mov %eax,0x82d36fc
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Recognize and skip interpreter_p initialization in selftest.exp
2006-02-26 20:23 ` Mark Kettenis
@ 2006-02-26 22:44 ` Daniel Jacobowitz
0 siblings, 0 replies; 5+ messages in thread
From: Daniel Jacobowitz @ 2006-02-26 22:44 UTC (permalink / raw)
To: Mark Kettenis; +Cc: fnf, gdb-patches
On Sun, Feb 26, 2006 at 08:37:55PM +0100, Mark Kettenis wrote:
> > From: Fred Fish <fnf@specifix.com>
> > Date: Sun, 26 Feb 2006 14:11:48 -0500
> >
> > On Sunday 26 February 2006 13:40, Daniel Jacobowitz wrote:
> > > happen? Could you please verify a couple of things for me: that we are
> > > reasonably close to the beginning of the function, that the prologue
> > > skipper hasn't gone too far, and that the instruction being executed
> > > has actually got some relationship to line 241.
> >
> > I'm not very familiar with x86 assembly so I'm probably not the best one
> > to look closely at the code generated for captured_main.
>
> The mov $0x1,%edi is probably initializing a local variable to 1. It
> is very unlikely that this instruction is part of line 241; it's much
> more likely this is line 186 or 189. I'd say, that GCC is generating
> bogus line number information or GDB is interpreting that line number
> information uncorrectly. Either way, your "fix" is probably papering
> over a real bug.
Yes - though I'm not sure yet if it's GCC's or GDB's. I get the same
thing on amd64 with GCC 4.0 and -O2, so I'll take a look.
Actually, I also get something somewhat annoying:
0x43f000 <captured_main>: push %r15
0x43f002 <captured_main+2>: xor %r15d,%r15d
0x43f005 <captured_main+5>: push %r14
0x43f007 <captured_main+7>: push %r13
0x43f009 <captured_main+9>: push %r12
0x43f00b <captured_main+11>: mov $0x1,%r12d
0x43f011 <captured_main+17>: push %rbp
0x43f012 <captured_main+18>: mov $0x1,%ebp
0x43f017 <captured_main+23>: push %rbx
0x43f018 <captured_main+24>: mov %rdi,%rbx
"break captured_main" stops on 0x43f000.
From the object file, where captured_main starts at 0x70:
Special opcode 173: advance Address by 12 to 0x70 and Line by 0 to 120
Advance Line by 121 to 241
Special opcode 33: advance Address by 2 to 0x72 and Line by 0 to 241
Advance Line by -121 to 120
Special opcode 47: advance Address by 3 to 0x75 and Line by 0 to 120
Advance Line by 121 to 241
It's definitely a GCC "issue", I'm not sure if "bug" applies. The
sched2 pass moves an insn from line 241 all the way up. But that
seems to have happened because ndir == 0 and cmdsize == 1 have gotten
associated with that line. It appears to be an artifact of SSA;
the loop is right after line 241, and the line number is being lost
when the initialization of ndir is propogated into the phi node.
Then it gets scheduled way up high again, which is unrelated.
This is now GCC PR 26475. Since it's been analyzed, and to prevent
cascading failures, maybe we should go with Fred's patch plus a
reference to the GCC PR?
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-02-26 20:23 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-02-26 18:40 [PATCH] Recognize and skip interpreter_p initialization in selftest.exp Fred Fish
2006-02-26 18:49 ` Daniel Jacobowitz
2006-02-26 19:38 ` Fred Fish
2006-02-26 20:23 ` Mark Kettenis
2006-02-26 22:44 ` Daniel Jacobowitz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox