All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <dan@debian.org>
To: Nathan Field <ndf@ghs.com>
Cc: linux-mips@linux-mips.org
Subject: Re: ptrace induced instruction cache bug?
Date: Tue, 13 Jan 2004 10:01:08 -0500	[thread overview]
Message-ID: <20040113150108.GA7144@nevyn.them.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0401121806240.1969-300000@zcar.ghs.com>

On Mon, Jan 12, 2004 at 06:34:57PM -0800, Nathan Field wrote:
> I'm writing a debugger that uses the Linux ptrace API for process control
> and I think I've found a bug in ptrace in MIPS Linux. The specific
> situation that breaks horribly with my debugger is quite complex, so I
> wrote a little testbed to show the problem. The code and a sample Makefile
> are attached. You can build the example for x86 or MIPS. I have some
> things in there for PPC but I haven't ported it fully yet. Basically the
> problem seems to be that writing a breakpoint (instruction 0xd), running 
> to the breakpoint, replacing the breakpoint with the original instruction 
> and then resuming sometimes results in the process halting on the same 
> address, even though there isn't a breakpoint there anymore. If you resume 
> again, or wait for a "while" after removing the breakpoint everything 
> works fine. I believe the problem is probably linked to some sort of 
> problem with the kernel not flushing the instruction cache, but that's 
> just a guess.

It sounds reasonable.  I've encountered this problem in the past also,
but never with the Pro 2.1 / MIPS release which is what you're using. 
I don't see anything obviously wrong with your test code, either.

> I'd guess that this problem has been fixed in later versions of the 
> kernel. If anyone can point me to a 2.4 release with this fixed I'd like 
> to know about it. I tried building the cvs checkout but the build failed. 
> It looks like I'll need a newer toolchain than the one I got from 
> MontaVista[1].
> 
> I'm using a stock MontaVista distribution for the MIPS Malta 4Kc in big
> endian mode, downloaded from their site a couple of days ago. I recompiled
> the kernel with the arch/mips/configs/defconfig-malta, but haven't changed 
> any options yet. Since that could be hard to classify here are some 
> details about my system:

Yes, you will need a newer toolchain.  Honestly, I'm baffled as to why
a Pro 2.1 toolchain was available from our web site at all, unless you
got it via an old product subscription... it should have been Pro 3.0,
which uses GCC 3.2 and a more recent binutils.  But I don't have any
control over these things :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

  reply	other threads:[~2004-01-13 15:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-13  2:34 ptrace induced instruction cache bug? Nathan Field
2004-01-13 15:01 ` Daniel Jacobowitz [this message]
2004-01-13 18:35   ` Nathan Field
2004-01-13 20:58     ` Daniel Jacobowitz
2004-01-14 23:36       ` Nathan Field
2004-01-15  0:07         ` Jun Sun
2004-01-15  0:22           ` Nathan Field
2004-01-15  0:22             ` Nathan Field
2004-01-15  0:40             ` Jun Sun

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=20040113150108.GA7144@nevyn.them.org \
    --to=dan@debian.org \
    --cc=linux-mips@linux-mips.org \
    --cc=ndf@ghs.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.