Re: Gdbserver error when debugging target MIPSEB from RedHat x86

[Daniel Jacobowitz <drow@false.org>]

On Tue, Mar 01, 2005 at 06:06:01PM -0500, Artie Mistler wrote:
> Sorry if the question is redundant, or if I've missed discussion on this
> subject in the archive.  I did try searching first.  I've seen this question
> asked in one other archive from a long time ago (2001), but the answer for
> that query was not an answer for my current problem.
> 
> I'm running Linux on an embedded target that has a MIPS big endian
> processor.  I've compiled gdbserver with host and target to be
> "mips-eb-linux-gnu".  And it runs on my target, established a remote
> debugging session with GDB from the debugging system.  GDB was created with
> host=x86 target=mipseb and it performs the target remote correctly, attaches
> to the process ID of the process being debugged under gdbserver.  I can set
> a breakpoint within the source, run to that point, print variables, display
> variables, however if I try to step, or continue, I receive a report on the
> target console: "ptrace: Input/output error."  My interpretation is this is
> due to an EIO occurring somewhere in gdbserver on the target.  However I
> haven't had much luck in tracking it down.  I do not have KDB available, and
> I'm not sure it would assist me with this problem.

I recommend using strace to find out what's going on, and then hook up
a real kernel debugger.  If ptrace is returning EIO, the problem is
unlikely to be in gdbserver.

> The target board here is a AMD DB1550 development board.  I'm wondering if
> there were other variations for target names that correspond to MIPS big
> endian that I might have chosen.  For instance, now that I'm summarizing
> this, I see that GDB used "mipseb" and gdbserver used "mips-eb-linux-gnu".
> I don't see matching target names in each respective directory though and
> that's why I chose one keyword for GDB and another for gdbserver.

Just use mips-linux-gnu.

> Also, in building the gdbserver, I had to edit the linux-mips-low.c file and
> change the #include <sys/reg.h> line to be <asm/reg.h> because there was no
> reg.h in the "sys" include tree.  I'm not sure if that's a fault of the
> linux distribution I'm using or a minor fault in the gdbserver code.  The
> compilation does work with that change, and can't get past pre-processing
> without that change, obviously.

Then you're not building gdbserver correctly; find out why
HAVE_SYS_REG_H was defined.

-- 
Daniel Jacobowitz
CodeSourcery, LLC