Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Emi SUZUKI <emi-suzuki@tjsys.co.jp>
To: Michael.Snyder@access-company.com
Cc: jimb@codesourcery.com, gdb@sourceware.org
Subject: Re: single-stepping and internal breakpoints on a multi-threaded  program
Date: Tue, 10 Apr 2007 08:38:00 -0000	[thread overview]
Message-ID: <20070410.172318.01365391.emi-suzuki@tjsys.co.jp> (raw)
In-Reply-To: <1175898309.11945.72.camel@svmsnyderlnx.palmsource.com>

Jim and Michael,

Thank you for your comments.  

From: Michael Snyder <Michael dot Snyder at access-company dot com>
Subject: Re: single-stepping and internal breakpoints on a multi-threaded program
Date: Fri, 06 Apr 2007 15:25:09 -0700

> > I have forgetten exactly how GDB handles multi-threaded single
> > stepping; I'm afraid I can't suggest how to do this.  If you're unable
> > to fix it yourself, please file a bug report, and include your test
> > program.
> 
> I'm thinking that gdb just loses the "I'm stepping this thread" 
> bit of state info, which is normally handled in "proceed" and 
> stored in the infrun-state struct - whereupon it just continues
> both threads without stepping.

I think it's true in some ways: it seemed that the clue for GDB to
decide that "I'm stepping this thread" is eventually only the value of
step_range_end.  

When the target get stopped on a thread different from which GDB
expected to stop, it was preserved in the thread_info structure by
context_switch, but never had an oppotunity to be looked back till the
target get stopped on that thread again.  It is not just lost, but no
better than lost.  

I think I should work more on the problem, but unfortunately, my
copyright assignment to FSF is still not ready.  So I will file it to
the bug tracking system, following Jim's advice.  
I will be back on it when I find that anything is not done for it
after my assignment is ready.  I hope not, though :-)

Thanks anyway, 
-- 
Emi SUZUKI


      reply	other threads:[~2007-04-10  8:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-05 11:57 Emi SUZUKI
2007-04-06 22:12 ` Jim Blandy
2007-04-06 22:25   ` Michael Snyder
2007-04-10  8:38     ` Emi SUZUKI [this message]

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=20070410.172318.01365391.emi-suzuki@tjsys.co.jp \
    --to=emi-suzuki@tjsys.co.jp \
    --cc=Michael.Snyder@access-company.com \
    --cc=gdb@sourceware.org \
    --cc=jimb@codesourcery.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