Re: [PATCH] Recognize and skip interpreter_p initialization in selftest.exp

[Daniel Jacobowitz <drow at false dot org>]

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