[ECOS] gdb remote debug problem

[ECOS] gdb remote debug problem

[Weilong Li]

Let me describe in detail the problem I encounted.

1) On my intel redhat 7.0 machine, I installed ecos1.3.1 under /opt/ecos
directory.

Then I download the development tools for Intel x86(i386-elf). I got the

latest snapshot for binutils (binutils-010417.tar.bz2), gcc-core
(gcc-core-20010416.tar) and gcc-g++(gcc-g++-20010416.tar), insight-5.0
(insight-5.0.tar.bz2), and installed them under /src directory.

2) under /opt/ecos directory, I created ecos-pcstub directory and
cd ecos-pcstub, then ecosconfig new pc stubs, then compile it, and
under install/bin directory, I found gdb_module.bin, so I
dd conv=sync if=./gdb_module.bin of=/dev/fd0h1440, then I see the floppy

disk is written. Then I create ecos-pc under /opt/ecos directory, type
ecosconfig new pc, and compile it. Go to /opt/ecos/ecos-1.3.1/examples,
open Makefile file, let PKG_INSTALL_DIR = /opt/ecos/ecos-pc/install,
and uncomment XCC = i386-elf-gcc, then make, and I see all the examples
file are compiled successfully.

3) Then I used the floppy disk to boot another computer, it is
intel 486 machine, I connected it with my intel redhat 7.0 machine using

a null modem cable. I saw the following things show on intel 486
machine:

++$T0508:a4370000;04:e00f0000;#19++$T0508:a43700019

So it seems the gdb stub on my target machine is working.
Then on intel redhat 7.0 machine, under directory
/opt/ecos/ecos-1.3.1/examples,
I typed i386-elf-gdb -nw hello, then the following shows:

GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "--host=i586-pc-linux-gnu
--target=i386-elf"...
(gdb) set remotebaud 38400
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Couldn't establish connection to remote target
Malformed response to offset query, timeout
(gdb) load
You can't do that when your target is `exec'

If I type i386-elf-gdb hello instead,
the graphic window shows up since I installed insight,

I saw the source code of atexit.cxx is shown in the window, under Run
menu,
I click on "connect to target" menuitem, and set target be "remote
serial",
and baud rate is 38400, and port is /dev/ttyS0, I clicked Ok, nothing
happens,
then I click "connect to target" menuitem under Run menu again, then
a dialog shows "Successfully connected". Then I click on "ok" button on
this
dialog, but the insight will exit and shows me "segmentation fault".

Anyway, I cannot connect to the target to do remote debugging, I guess
there is something wrong with physical connection to the target machine.

On the host (intel Redhat 7.0 machine), there are two ports with D9
interface, I don't know how to distinguish between com1 and com2, so I
just tried both of them, and got the same results above.(on my target
machine,
 there is only one D9 interface).


Please tell me what is wrong and what should I do so that I can
do remote debugging. thanks a lot.

Re: [ECOS] gdb remote debug problem

[elf]

I've done exactly the same thing with success. I encountered some odd
behavior when I didn't use exactly the software versions recommended
by the eCos team.  I used:

  binutils-2.11.90.0.1
  gcc-core-2.95.2
  gcc-g++-2.95.2
  insight-5.0

though the behavior you describe seems to indicate that the tools are
correctly built.

The most important thing to check is that your serial connection is
correct.  It is worthwhile to use minicom (or a similar package) to
test the physical, serial link.

 -*-

[deletia]

> 3) Then I used the floppy disk to boot another computer, it is
> intel 486 machine, I connected it with my intel redhat 7.0 machine using
> 
> a null modem cable. I saw the following things show on intel 486
> machine:
> 
> ++$T0508:a4370000;04:e00f0000;#19++$T0508:a43700019
> 
> So it seems the gdb stub on my target machine is working.
> Then on intel redhat 7.0 machine, under directory
> /opt/ecos/ecos-1.3.1/examples,
> I typed i386-elf-gdb -nw hello, then the following shows:
> 
> GNU gdb 5.0
> Copyright 2000 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> This GDB was configured as "--host=i586-pc-linux-gnu
> --target=i386-elf"...
> (gdb) set remotebaud 38400
> (gdb) target remote /dev/ttyS0
> Remote debugging using /dev/ttyS0
> Ignoring packet error, continuing...
> Ignoring packet error, continuing...
> Ignoring packet error, continuing...
> Couldn't establish connection to remote target
> Malformed response to offset query, timeout
> (gdb) load
> You can't do that when your target is `exec'
> 
> If I type i386-elf-gdb hello instead,
> the graphic window shows up since I installed insight,
> 
> I saw the source code of atexit.cxx is shown in the window, under Run
> menu,
> I click on "connect to target" menuitem, and set target be "remote
> serial",
> and baud rate is 38400, and port is /dev/ttyS0, I clicked Ok, nothing
> happens,
> then I click "connect to target" menuitem under Run menu again, then
> a dialog shows "Successfully connected". Then I click on "ok" button on
> this
> dialog, but the insight will exit and shows me "segmentation fault".
> 
> Anyway, I cannot connect to the target to do remote debugging, I guess
> there is something wrong with physical connection to the target machine.
> 
> On the host (intel Redhat 7.0 machine), there are two ports with D9
> interface, I don't know how to distinguish between com1 and com2, so I
> just tried both of them, and got the same results above.(on my target
> machine,
>  there is only one D9 interface).
> 
> 
> Please tell me what is wrong and what should I do so that I can
> do remote debugging. thanks a lot.
> 
> 

Re: [ECOS] gdb remote debug problem

[elf]

Today, when I started to do the same thing that worked for me
yesterday, I am getting the behavior you describe.  

I enabled a remotelogfile in GDB and discovered that the remote end
was sending an the initial string, but never responding to further
communication.  I'm guesing that my stub isn't running properly.

 - * -  From the log file

 w $qC#b4
 r ++$T0508:ec370000;04:e00f0000;#4c
 w +$qOffsets#4b
 r <Timeout: 2 seconds>
 w $qOffsets#4b

This is unexpected as this was working OK so recently and I've not
made either hardware or software changes...that I can think of.

 

Re: [ECOS] gdb remote debug problem

[elf]

Another factoid.

I stop GDB.  Print the contents of the log file.  Open minicom with
the correct baudrate.  Type the string the string "+$Hc-1#09" and
receive a reasonable response from the GDB stub, "+$#00".  Oddly, GDB
doesn't log any such response.

Re: [ECOS] gdb remote debug problem

[Gary Thomas]

On 22-Apr-2001 elf@florence.buici.com wrote:
> Today, when I started to do the same thing that worked for me
> yesterday, I am getting the behavior you describe.  
> 
> I enabled a remotelogfile in GDB and discovered that the remote end
> was sending an the initial string, but never responding to further
> communication.  I'm guesing that my stub isn't running properly.
> 
>  - * -  From the log file
> 
>  w $qC#b4
>  r ++$T0508:ec370000;04:e00f0000;#4c
>  w +$qOffsets#4b
>  r <Timeout: 2 seconds>
>  w $qOffsets#4b
> 
> This is unexpected as this was working OK so recently and I've not
> made either hardware or software changes...that I can think of.
> 
>  

Try typing in the "w" lines manually and see what happens.  I have seen
cases where the '+$qOffsets#4b' came in too fast for the target to 
handle.  If this works manually, try generating the target code to run
at a different baud rate, say 19200, instead of 38400.  Then in GDB you'll
need to try:
  (gdb) set remotebaud 19200
  (gdb) tar rem /dev/XXX

Re: [ECOS] gdb remote debug problem

[elf]

I discovered the difference between yesterday and today.

Today, when I started doing this work, I created a script to configure
the environment that changed the PATH environment variable to include
/usr/local/ecos/i386/bin where I put the toolchain executables.

Yesterday, I used a tcsh command to put this path element at the head
of the 'path' list.

  set path = (/usr/local/ecos/i386/bin $path)

I'm not sure why this makes a difference.  When I set the path today
using this method, gdb works. 

Re: [ECOS] gdb remote debug problem

[elf]

By the way, the standard GDB for an x86 linux host appears to work
just fine.  I've been using it for some time and just noticed that I
wasn't using the i386-elf version.

Re: [ECOS] gdb remote debug problem

[Weilong Li]

Elf, thanks a lot for help.

I just discovered the problem. The target machine is so old that its serial
port
is rusted, and I tried anoter target, it is working.

Weilong

elf@florence.buici.com wrote:

> I've done exactly the same thing with success. I encountered some odd
> behavior when I didn't use exactly the software versions recommended
> by the eCos team.  I used:
>
>   binutils-2.11.90.0.1
>   gcc-core-2.95.2
>   gcc-g++-2.95.2
>   insight-5.0
>
> though the behavior you describe seems to indicate that the tools are
> correctly built.
>
> The most important thing to check is that your serial connection is
> correct.  It is worthwhile to use minicom (or a similar package) to
> test the physical, serial link.
>
>  -*-
>
> [deletia]
>
> > 3) Then I used the floppy disk to boot another computer, it is
> > intel 486 machine, I connected it with my intel redhat 7.0 machine using
> >
> > a null modem cable. I saw the following things show on intel 486
> > machine:
> >
> > ++$T0508:a4370000;04:e00f0000;#19++$T0508:a43700019
> >
> > So it seems the gdb stub on my target machine is working.
> > Then on intel redhat 7.0 machine, under directory
> > /opt/ecos/ecos-1.3.1/examples,
> > I typed i386-elf-gdb -nw hello, then the following shows:
> >
> > GNU gdb 5.0
> > Copyright 2000 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you
> > are
> > welcome to change it and/or distribute copies of it under certain
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for
> > details.
> > This GDB was configured as "--host=i586-pc-linux-gnu
> > --target=i386-elf"...
> > (gdb) set remotebaud 38400
> > (gdb) target remote /dev/ttyS0
> > Remote debugging using /dev/ttyS0
> > Ignoring packet error, continuing...
> > Ignoring packet error, continuing...
> > Ignoring packet error, continuing...
> > Couldn't establish connection to remote target
> > Malformed response to offset query, timeout
> > (gdb) load
> > You can't do that when your target is `exec'
> >
> > If I type i386-elf-gdb hello instead,
> > the graphic window shows up since I installed insight,
> >
> > I saw the source code of atexit.cxx is shown in the window, under Run
> > menu,
> > I click on "connect to target" menuitem, and set target be "remote
> > serial",
> > and baud rate is 38400, and port is /dev/ttyS0, I clicked Ok, nothing
> > happens,
> > then I click "connect to target" menuitem under Run menu again, then
> > a dialog shows "Successfully connected". Then I click on "ok" button on
> > this
> > dialog, but the insight will exit and shows me "segmentation fault".
> >
> > Anyway, I cannot connect to the target to do remote debugging, I guess
> > there is something wrong with physical connection to the target machine.
> >
> > On the host (intel Redhat 7.0 machine), there are two ports with D9
> > interface, I don't know how to distinguish between com1 and com2, so I
> > just tried both of them, and got the same results above.(on my target
> > machine,
> >  there is only one D9 interface).
> >
> >
> > Please tell me what is wrong and what should I do so that I can
> > do remote debugging. thanks a lot.
> >
> >

Re: [ECOS] gdb remote debug problem

[elf]

On Thu, Apr 26, 2001 at 06:52:34AM -0400, Weilong Li wrote:
> Elf, thanks a lot for help.
> 
> I just discovered the problem. The target machine is so old that its serial
> port
> is rusted, and I tried anoter target, it is working.

Rusted.  Wow.

> 
> Weilong
> 
> elf@florence.buici.com wrote:
> 
> > I've done exactly the same thing with success. I encountered some odd
> > behavior when I didn't use exactly the software versions recommended
> > by the eCos team.  I used:
> >
> >   binutils-2.11.90.0.1
> >   gcc-core-2.95.2
> >   gcc-g++-2.95.2
> >   insight-5.0
> >
> > though the behavior you describe seems to indicate that the tools are
> > correctly built.
> >
> > The most important thing to check is that your serial connection is
> > correct.  It is worthwhile to use minicom (or a similar package) to
> > test the physical, serial link.
> >
> >  -*-
> >
> > [deletia]
> >
> > > 3) Then I used the floppy disk to boot another computer, it is
> > > intel 486 machine, I connected it with my intel redhat 7.0 machine using
> > >
> > > a null modem cable. I saw the following things show on intel 486
> > > machine:
> > >
> > > ++$T0508:a4370000;04:e00f0000;#19++$T0508:a43700019
> > >
> > > So it seems the gdb stub on my target machine is working.
> > > Then on intel redhat 7.0 machine, under directory
> > > /opt/ecos/ecos-1.3.1/examples,
> > > I typed i386-elf-gdb -nw hello, then the following shows:
> > >
> > > GNU gdb 5.0
> > > Copyright 2000 Free Software Foundation, Inc.
> > > GDB is free software, covered by the GNU General Public License, and you
> > > are
> > > welcome to change it and/or distribute copies of it under certain
> > > conditions.
> > > Type "show copying" to see the conditions.
> > > There is absolutely no warranty for GDB.  Type "show warranty" for
> > > details.
> > > This GDB was configured as "--host=i586-pc-linux-gnu
> > > --target=i386-elf"...
> > > (gdb) set remotebaud 38400
> > > (gdb) target remote /dev/ttyS0
> > > Remote debugging using /dev/ttyS0
> > > Ignoring packet error, continuing...
> > > Ignoring packet error, continuing...
> > > Ignoring packet error, continuing...
> > > Couldn't establish connection to remote target
> > > Malformed response to offset query, timeout
> > > (gdb) load
> > > You can't do that when your target is `exec'
> > >
> > > If I type i386-elf-gdb hello instead,
> > > the graphic window shows up since I installed insight,
> > >
> > > I saw the source code of atexit.cxx is shown in the window, under Run
> > > menu,
> > > I click on "connect to target" menuitem, and set target be "remote
> > > serial",
> > > and baud rate is 38400, and port is /dev/ttyS0, I clicked Ok, nothing
> > > happens,
> > > then I click "connect to target" menuitem under Run menu again, then
> > > a dialog shows "Successfully connected". Then I click on "ok" button on
> > > this
> > > dialog, but the insight will exit and shows me "segmentation fault".
> > >
> > > Anyway, I cannot connect to the target to do remote debugging, I guess
> > > there is something wrong with physical connection to the target machine.
> > >
> > > On the host (intel Redhat 7.0 machine), there are two ports with D9
> > > interface, I don't know how to distinguish between com1 and com2, so I
> > > just tried both of them, and got the same results above.(on my target
> > > machine,
> > >  there is only one D9 interface).
> > >
> > >
> > > Please tell me what is wrong and what should I do so that I can
> > > do remote debugging. thanks a lot.
> > >
> > >