annota1.exp

annota1.exp

[Mark Kettenis]

Hi folks,

I'm seeing new failures in annota1.exp (on OpenBSD/i386 at least):

FAIL: gdb.base/annota1.exp: send SIGUSR1
FAIL: gdb.base/annota1.exp: signal sent

The problem seems to be that with a freshly built GDB I get:


signal SIGUSR1

^Z^Zpost-prompt
Continuing with signal SIGUSR1.

^Z^Zframes-invalid

^Z^Zstarting


but the expect pattern checks for the "frames-invalid" and "starting"
lines in reverse order:


        -re "\r\n\032\032post-prompt\r\nContinuing with signal SIGUSR1.\r\n\r\n\032\032starting\(\r\n\r\n\032\032frames-invalid\)+


Are people seeing the same thing on other platforms?

Re: annota1.exp

[Pedro Alves]

On Saturday 04 July 2009 21:30:59, Mark Kettenis wrote:
> Hi folks,
> 
> I'm seeing new failures in annota1.exp (on OpenBSD/i386 at least):
> 
> FAIL: gdb.base/annota1.exp: send SIGUSR1

Hmmm, sounds suspiciously related, or does it look like you have
a new issue masking that other one?

 http://sourceware.org/ml/gdb/2009-02/msg00080.html

There's now a reinit_frame_cache call in regcache_write_pc.
Did you revert Daniel's patch in your tree perhaps?  That
would account for the extra "frames-invalid" output, I guess.

> The problem seems to be that with a freshly built GDB I get:
> 
> 
> signal SIGUSR1
> 
> ^Z^Zpost-prompt
> Continuing with signal SIGUSR1.
> 
> ^Z^Zframes-invalid

Looks like there's a registers_changed or reinit_frame_cache call
somewhere between 

> 
> ^Z^Zstarting
> 
> 
> but the expect pattern checks for the "frames-invalid" and "starting"
> lines in reverse order:
> 
> 
>         -re "\r\n\032\032post-prompt\r\nContinuing with signal SIGUSR1.\r\n\r\n\032\032starting\(\r\n\r\n\032\032frames-invalid\)+
> 
> 
> Are people seeing the same thing on other platforms?

Here's what I get on x86_64-linux:

 signal SIGUSR1

 ^Z^Zpost-prompt
 Continuing with signal SIGUSR1.

 ^Z^Zstarting

 ^Z^Zframes-invalid

 ^Z^Zframes-invalid

 ^Z^Zbreakpoint 2

 Breakpoint 2,
 ^Z^Zframe-begin 0 0x40052f

> FAIL: gdb.base/annota1.exp: signal sent

Here's what I get:

 PASS: gdb.base/annota1.exp: breakpoint ignore count
 signal SIGTRAP

 ^Z^Zpost-prompt
 Continuing with signal SIGTRAP.

 ^Z^Zstarting

 ^Z^Zframes-invalid

 ^Z^Zsignalled

 Program terminated with signal
 ^Z^Zsignal-name
 SIGTRAP
 ^Z^Zsignal-name-end
 ,
 ^Z^Zsignal-string
 Trace/breakpoint trap
 ^Z^Zsignal-string-end
.
 The program no longer exists.

 ^Z^Zstopped

 ^Z^Zpre-prompt
 (gdb)
 ^Z^Zprompt
 PASS: gdb.base/annota1.exp: signal sent

-- 
Pedro Alves

Re: annota1.exp

[Mark Kettenis]

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Sat, 4 Jul 2009 22:12:22 +0100
> 
> On Saturday 04 July 2009 21:30:59, Mark Kettenis wrote:
> > Hi folks,
> > 
> > I'm seeing new failures in annota1.exp (on OpenBSD/i386 at least):
> > 
> > FAIL: gdb.base/annota1.exp: send SIGUSR1
> 
> Hmmm, sounds suspiciously related, or does it look like you have
> a new issue masking that other one?
> 
>  http://sourceware.org/ml/gdb/2009-02/msg00080.html
> 
> There's now a reinit_frame_cache call in regcache_write_pc.
> Did you revert Daniel's patch in your tree perhaps?  That
> would account for the extra "frames-invalid" output, I guess.

I still have the reversion of Daniel's change in my tree, and it does
indeed account for the reordering.

annota1.exp

[Nick Roberts]

I don't see this on x86_64-linux-gnu.  FWIW, Emacs doesn't use the frames-invalid
annotation.  It, along with the breakpoints-invalid annotation, fires far too frequently.

Emacs uses a reduced set of annotations, which we called level 3, created back
in about 2004 when Andrew Cagney was release manager.  The plan was to remove
those which weren't in that set and I did submit a patch to do this
(http://sourceware.org/ml/gdb-patches/2005-06/msg00189.html).  If maintenance
of these tests becomes a burden people might like to reconsider this option.

-- 
Nick                                           http://www.inet.net.nz/~nickrob