linux-mips
[Top] [All Lists]

Re: Debugging the MIPS processor using GDB

To: Brian Foster <brian.foster@innova-card.com>
Subject: Re: Debugging the MIPS processor using GDB
From: "Maciej W. Rozycki" <macro@linux-mips.org>
Date: Wed, 13 Aug 2008 16:16:41 +0100 (BST)
Cc: linux-mips@linux-mips.org, Martin Gebert <martin.gebert@alpha-bit.de>, TriKri <kristoferkrus@hotmail.com>
In-reply-to: <200808131707.30570.brian.foster@innova-card.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <18944199.post@talk.nabble.com> <200808130905.53671.brian.foster@innova-card.com> <Pine.LNX.4.55.0808131441160.390@cliff.in.clinika.pl> <200808131707.30570.brian.foster@innova-card.com>
Sender: linux-mips-bounce@linux-mips.org
On Wed, 13 Aug 2008, Brian Foster wrote:

>   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.

 That should not matter.  For example you could boot your system in the
usual way provided by the firmware and attach to an already running
kernel.  The probe does not know or care about that.

>   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!

 Your situation looks pretty miserable -- you should definitely pester 
FS2.

  Maciej

<Prev in Thread] Current Thread [Next in Thread>