Gdbserver error when debugging target MIPSEB from RedHat x86

Gdbserver error when debugging target MIPSEB from RedHat x86

[Artie Mistler]

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.

The former question elicited a response that the version of GDB was too old.
I have the a fairly recent version of the GNU toolkit, 6.3 and I created
both GDB and gdbserver from this distribution.

Additional information is that we used to operate our product in little
endian mode, performed the same preparations by building the toolkit
appropriately, and everything worked.

I'm assuming that because GDB and gdbserver run under their respective
locations, they've been built properly, and since they communicate somewhat,
they're close to what they should be.

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.

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.

Any info would be helpful.

Regards,
- RT

RT Mistler
Performance Technologies, Inc.
Voice Technology Group
315 Norwood Park
Norwood, MA  02062
(781) 751-2415
Fax: (781) 751-2470
amistler@pt.com

Visit our web site at: http://www.pt.com

Re: Gdbserver error when debugging target MIPSEB from RedHat x86

[Daniel Jacobowitz]

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

RE: Gdbserver error when debugging target MIPSEB from RedHat x86

[Artie Mistler]

The solution turned out to be:

Build GDB with host=x86, target=mips-linux
Build GDBSERVER with mips-linux-gnu

Thanks for the suggestions.

Regards,
- RT

-----Original Message-----
From: Daniel Jacobowitz [mailto:drow@false.org]
Sent: Tuesday, March 01, 2005 6:32 PM
To: Artie Mistler
Cc: 'gdb@sources.redhat.com'
Subject: Re: Gdbserver error when debugging target MIPSEB from RedHat
x86


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