Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Elizabeth Chastain <mec@shout.net>
To: drow@mvista.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] port simple gdb.threads/schedlock.c test fix to branch
Date: Mon, 02 Dec 2002 21:19:00 -0000	[thread overview]
Message-ID: <200212030519.gB35JOt21685@duracef.shout.net> (raw)

> This is OK for the branch.  I think I meant to do it at the time and
> dropped the ball. I should also check that the lin-lwp fix for
> schedlock.exp made the branch...

From the black box point of view, gdb HEAD and gdb 5.3 branch are
behaving very differently with schedlock.exp.  This is with all the
same compilers and binutils and yada.  gdb HEAD gives me 2 FAILs
consistently, and gdb 5.3 branch gives me 8 FAILs most of the time
and 4 FAILs some of the time.

Gory details below.

My version is from 2002-11-25, a week ago, and you checked in one
fix to lin-lwp.c since then, to call linux_proc_xfer_memory.
Is that the fix that lin-lwp.c needs?

Michael C

  schedlock.exp FAILs

    gdb.thread/schedlock.exp: thread 0 ran (didn't run)
    gdb.thread/schedlock.exp: thread 1 ran (didn't run)
      ++ happened in all gdb HEAD configurations (130 of 130)
      ++ did not happen in gdb gdb_5_3-branch
      ++ script did not exist in gdb 5.2.1

    gdb.thread/schedlock.exp: thread 0 ran (didn't run)
    gdb.thread/schedlock.exp: thread 1 ran (didn't run)
    gdb.threads/schedlock.exp: continue with lock does not change thread (switched to thread 3)
    gdb.threads/schedlock.exp: other thread 3 didn't run (ran)
    gbd.threads/schedlock.exp: other thread 4 didn't run (ran)
    gdb.threads/schedlock.exp: step with lock does not change thread (switched to thread 3)
    gdb.threads/schedlock.exp: current thread stepped locked (didn't run)
    gdb.threads/schedlock.exp: other thread 3 didn't run (stepping) (ran)
      ++ never happened in gdb HEAD
      ++ happened in most gdb gdb_5_3-branch configurations (99 of 130)
      ++ script did not exist in gdb 5.2.1
      ++ not correlated with gcc version or binutils version

    gdb.thread/schedlock.exp: thread 0 ran (didn't run)
    gdb.thread/schedlock.exp: thread 1 ran (didn't run)
    gdb.threads/schedlock.exp: other thread 3 didn't run (ran)
    gbd.threads/schedlock.exp: other thread 4 didn't run (ran)
      ++ never happened in gdb HEAD
      ++ happened in some gdb gdb_5_3-branch configurations (31 of 130)
      ++ script did not exist in gdb 5.2.1
      ++ not correlated with gcc version or binutils version


             reply	other threads:[~2002-12-03  5:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-02 21:19 Michael Elizabeth Chastain [this message]
2002-12-02 21:23 ` Daniel Jacobowitz
  -- strict thread matches above, loose matches on Subject: below --
2002-12-02 20:20 Michael Elizabeth Chastain
2002-12-02 20:29 ` 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=200212030519.gB35JOt21685@duracef.shout.net \
    --to=mec@shout.net \
    --cc=drow@mvista.com \
    --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