Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Brian Foster <brian.foster@innova-card.com>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: linux-mips@linux-mips.org,
	Martin Gebert <martin.gebert@alpha-bit.de>,
	TriKri <kristoferkrus@hotmail.com>
Subject: Re: Debugging the MIPS processor using GDB
Date: Wed, 13 Aug 2008 17:07:30 +0200	[thread overview]
Message-ID: <200808131707.30570.brian.foster@innova-card.com> (raw)
In-Reply-To: <Pine.LNX.4.55.0808131441160.390@cliff.in.clinika.pl>

On Wednesday 13 August 2008 15:49:39 Maciej W. Rozycki wrote:
> On Wed, 13 Aug 2008, Brian Foster wrote:
> 
> >   Re the FS²:  [ ... ]  at least one thing doesn't work
> >  reliably for me [ ... ]:  Breakpoints in the Linux kernel.
> >  They do detonate.  Then, sometimes, I can ‘c’(ontinue) or
> >  ‘s’(tep) Ok.  But other times, when I ‘c’ or ‘s’, the
> >  breakpoint detonates again and I'm stuck.  [ ... ]
> 
>  Hmm, odd.  It looks like a cache coherence issue.

Maciej,

  That would be my guess also.

>  It could be a bug in your version of FS2 software -- did you raise the issue with them?  

  I've been trying to.  (I cannot say more on this ATM, sorry!)

  I'm using the most recent FS² (2.4.4) with the most recent
 SDE-Lite from MIPS (V6.06.01).  Older versions of FS²/SDE
 had the same(?) issue.  (This is with a 4KSd core, running
 Little Endian.)

  What _might_ be an issue/cause is we're using our own
 home-grown ‘gdb’ scripts (to init the memory, load the
 kernel, etc.).  I didn't write them, but I have looked
 them over, and they _look_ Ok to me.


> Anyway, as a workaround try setting "coherent=on" (quoting from memory)
> in fs2.ini (just an idea -- it may not work and you will lose some
> performance though) or use hardware breakpoints.

  As it turns out, I _have_ been running Coherent On!
 So I tried turning if Off, just to see what would happen.
 No difference.

  The behavior I saw was:

    1. gdb     b xxx_open
    2. target  cat /dev/xxx
    3. (breakpoint detonates)
    4. gdb     x/i $pc     (all is Ok)
    5. gdb     c           (Ok)
    6. target  cat /dev/xxx
    7. (breakpoint detonates)
    8. gdb     x/i $pc     (wrong! instruction is ‘sdbbp’.)

  I'm now stuck.  Any attempt to ‘c’ or ‘s’ just hits the
 breakpoint again.

  I tried some “mdi cacheflush” at some plausible-seeming
 points, all to no effect.  I also tried deleting the
 breakpoint (after step 8), which was a disaster:  (From
 memory) when I then ‘c’(ontinued), ‘gdb’ hung, and the
 ‘sysnav’ went into an infinite loop of reporting a
 breakpoint.  ;-(

 ( I seem to recall also having an issue with hardware
  breakpoints, but cannot recall for certain ATM; tests
  will have to wait until later ....  ;-\  )

  All ideas and suggestions are very welcome!

cheers!
	-blf-

-- 
“How many surrealists does it take to   | Brian Foster
 change a lightbulb? Three. One calms   | somewhere in south of France
 the warthog, and two fill the bathtub  |   Stop E$$o (ExxonMobil)!
 with brightly-coloured machine tools.” |      http://www.stopesso.com

  reply	other threads:[~2008-08-13 15:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-12 13:23 Debugging the MIPS processor using GDB TriKri
2008-08-12 14:14 ` Martin Gebert
2008-08-12 14:37   ` Brian Foster
2008-08-12 16:27     ` Maciej W. Rozycki
2008-08-13  7:05       ` Brian Foster
2008-08-13 13:49         ` Maciej W. Rozycki
2008-08-13 15:07           ` Brian Foster [this message]
2008-08-13 15:16             ` Maciej W. Rozycki
2008-08-14 11:42             ` Debugging the MIPS processor using GDB (and FS2 EJTAG probe breakpoint issues) Brian Foster
2008-08-14 23:11               ` Maciej W. Rozycki
2008-08-13 14:41         ` Debugging the MIPS processor using GDB Jon Fraser
2008-08-13 15:12           ` Brian Foster

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=200808131707.30570.brian.foster@innova-card.com \
    --to=brian.foster@innova-card.com \
    --cc=kristoferkrus@hotmail.com \
    --cc=linux-mips@linux-mips.org \
    --cc=macro@linux-mips.org \
    --cc=martin.gebert@alpha-bit.de \
    /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