Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Nick Roberts <nickrob@snap.net.nz>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] -data-list-changed-registers (Take 2)
Date: Tue, 14 Jun 2005 02:45:00 -0000	[thread overview]
Message-ID: <17070.17646.968472.157418@farnswood.snap.net.nz> (raw)
In-Reply-To: <20050613224215.GA13598@nevyn.them.org>

 > > I get many failures on the testsuite, I'll try to move to a newer
 > > PC/kernel.  mi-regs.exp seems OK though.
 > 
 > What failures, in particular?

I don't think you'll want to know, I think a lot of them are kernel
related (2.4.19-16mdk).  I've attached the results below of a run with a
newer kernel (2.6.9.1-1.667 Fedora Core 3)

 > > I would like to commit my changes to -var-update (2005-05-02) sometime.
 > 
 > Sorry, I need to take another look at them.  I will try to to find the
 > time.

Thanks.

 > > I have also removed a large number of annotations from my working copy.
 > > Andrew started this process, it would be nice if he can be involved but
 > > maybe thats not possible. There are a lot of changes to the following
 > > files:
 ...
 > > 
 > > Is anyone interested?  It would be good to do this now as a release doesn't
 > > seem to be imminent.
 > 
 > I can try to take a look at it.  I do not know much about the existing
 > annotations or how people use them; that's why it takes me a long time
 > to review any patches in this area.

OK.  I'll check my changes a bit more carefully and then submit them.

I've made more changes to gdb-mi.el now (it use -data-list-changed-registers
now, for a start).  Since resources do seem to be stretched, and this is
separate code that can't break GDB, could I be given authority to check in
changes to this just this one file i.e. in MAINTAINERS:

Core: Generic components used by all of GDB
...
gdb-mi.el               nickrob@snap.net.nz 

I did suggest this once to Andrew, but it never got resolved.  It might need
an emergency general meeting and you might have to dust off a copy of the
Constitution, but in reality its no big deal.  I've been doing something like
this for Emacs for a couple of years now without problems.

Nick


FAIL: gdb.base/store.exp: var longest l; print old r, expecting -2
FAIL: gdb.base/store.exp: upvar longest l; print old r, expecting -2
FAIL: gdb.cp/annota3.exp: annotate-quit (pattern 1)
FAIL: gdb.cp/anon-union.exp: print w 1
FAIL: gdb.cp/anon-union.exp: print z 1
FAIL: gdb.cp/anon-union.exp: print w 2
FAIL: gdb.cp/anon-union.exp: print z 2
FAIL: gdb.cp/anon-union.exp: print w 3
FAIL: gdb.cp/anon-union.exp: print z 3
FAIL: gdb.java/jmisc.exp: p args
FAIL: gdb.java/jmisc1.exp: p args
FAIL: gdb.java/jprint.exp: unambiguous static call
FAIL: gdb.java/jprint.exp: single argument print call
FAIL: gdb.java/jprint.exp: double argument print call
FAIL: gdb.java/jprint.exp: virtual fn call
FAIL: gdb.java/jprint.exp: inherited static call
FAIL: gdb.java/jprint.exp: inherited virtual fn call
FAIL: gdb.mi/mi-basics.exp: environment-directory arg operation
FAIL: gdb.mi/mi-basics.exp: environment-directory empty-string operation
FAIL: gdb.mi/mi-basics.exp: environment-path dir1 dir2 operation
FAIL: gdb.mi/mi-file.exp: Getting a list of source files.
FAIL: gdb.mi/mi2-basics.exp: environment-directory arg operation
FAIL: gdb.mi/mi2-basics.exp: environment-directory empty-string operation
FAIL: gdb.mi/mi2-basics.exp: environment-path dir1 dir2 operation
FAIL: gdb.threads/thread_check.exp: breakpoint at tf
FAIL: gdb.threads/watchthreads.exp: threaded watch loop
FAIL: gdb.threads/watchthreads.exp: first watchpoint on args[1] hit
FAIL: gdb.threads/watchthreads.exp: watchpoint on args[1] hit in thread
FAIL: gdb.threads/watchthreads.exp: combination of threaded watchpoints = 30

		=== gdb Summary ===

# of expected passes		10777
# of unexpected failures	29
# of unexpected successes	1
# of expected failures		42
# of unknown successes		6
# of known failures		38
# of untested testcases		1
# of unsupported tests		9


  reply	other threads:[~2005-06-14  2:45 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-01 11:12 [PATCH] -data-list-changed-registers Nick Roberts
2005-06-03 19:13 ` Daniel Jacobowitz
2005-06-03 22:35   ` Nick Roberts
2005-06-03 22:36     ` Daniel Jacobowitz
2005-06-04 11:41       ` Nick Roberts
2005-06-06 20:44         ` Nick Roberts
2005-06-11  5:54           ` Nick Roberts
2005-06-11  6:50           ` [PATCH] -data-list-changed-registers (Take 2) Nick Roberts
2005-06-13  2:40             ` Daniel Jacobowitz
2005-06-13  4:47               ` Nick Roberts
2005-06-13 13:48                 ` Daniel Jacobowitz
2005-06-13 22:38                   ` Nick Roberts
2005-06-13 22:42                     ` Daniel Jacobowitz
2005-06-14  2:45                       ` Nick Roberts [this message]
2005-06-17  1:51                         ` Daniel Jacobowitz
2005-06-17  3:13                           ` Nick Roberts
2005-06-17  3:22                             ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17070.17646.968472.157418@farnswood.snap.net.nz \
    --to=nickrob@snap.net.nz \
    --cc=drow@false.org \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox