How to configure gdb on arm-linux (for CDB89712)

How to configure gdb on arm-linux (for CDB89712)

[Dmytro Bablinyuk]

I built arm-linux and put it on the board. Also I built a cross-compiler 
(using uclibc)
I've done everything as described in
http://roland.seuhs.com/en/index.php/Development/LiMa/CDB89712

When I came to the point that I need to debug an application I got stuck 
(hello world perfectly works on target as standalone application but not 
with gdb).

I tried to build a cross-platform gdb and gdbserver. I tried below
steps to do this:

1.Unpack gdb

  $cd $ARM_ROOT/src
  $tar xzvf ../dl/gdb-5.3.tar.gz

Make symbolic link (easier for next steps if you don't have same
version)

  $ln -s gdb-5.3 gdb

2. Build gdb

  $cd $ARM_ROOT/src/gdb/
  $./configure --host=i686-pc-linux-gnu --target=arm-linux
  $make
  $strip gdb/gdb

Check that we client for Intel platform:

  [root@sardine gdb]# file gdb/gdb
  gdb/gdb: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), stripped
  [root@sardine gdb]#

  $cp gdb/gdb /usr/local/bin/arm-gdb

3. Build gdbserver

  $cd $ARM_ROOT/src/gdb/gdb/gdbserver/
  $chmod u+x configure

Remove cache file

  $rm config.cache
  $export CC=$ARM_ROOT/arm-linux-uclibc/bin/arm-uclibc-gcc
  $./configure --target=arm-linux --host=arm-linux --build=i386-linux
  $make clean
  $make

Check output file

  [root@sardine gdbserver]# file gdbserver
  gdbserver: ELF 32-bit LSB executable, ARM, version 1 (ARM),
dynamically linked (uses shared libs), not stripped
  [root@sardine gdbserver]#

Copy into the target's ramdisk

  $cp gdbserver $ARM_ROOT/ramdisk/target/usr/bin/


As result I got a Illegal Instruction message when I started this up.

On host:

[Dmytro@sardine Dmytro]$ arm-gdb -nw
$ARM_ROOT/ramdisk/target/armdevelop/hello
GNU gdb 5.2.1
Copyright 2002 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=i686-pc-linux-gnu
--target=arm-linux"...
(gdb) target remote 172.25.193.23:1023
Remote debugging using 172.25.193.23:1023
0x00008110 in _start ()
(gdb) b main
Breakpoint 1 at 0x8158: file hello.c, line 4.
(gdb) c
Continuing.

Program received signal SIGILL, Illegal instruction.
0x00008114 in _start ()
(gdb)


On target(CDB89712)

# gdbserver 172.25.140.19:1023 /armdevelop/hello
Process /armdevelop/hello created; pid = 196
Remote debugging from host 172.25.140.19
hello(135): undefined instruction: pc=00008114
Code: e91ba800 e3a0b000 (e7ffdefe) e1a0100d e0812100
Killing inferior
#

And then

# tail /var/log/messages
Jan  1 05:53:56 name user.warn klogd: Code: e91ba800 e3a0b000
(e7ffdefe) e1a0100d e0812100
Jan  1 05:59:15 name syslog.info -- MARK --
Jan  1 06:19:15 name syslog.info -- MARK --
Jan  1 06:39:15 name syslog.info -- MARK --
Jan  1 06:59:15 name syslog.info -- MARK --
Jan  1 07:19:15 name syslog.info -- MARK --
Jan  1 07:20:31 name user.info klogd: hello (183): undefined
instruction: pc=00008114
Jan  1 07:20:31 name user.warn klogd: Code: e91ba800 e3a0b000
(e7ffdefe) e1a0100d e0812100
Jan  1 07:22:14 name user.info klogd: hello (185): undefined
instruction: pc=00008114
Jan  1 07:22:14 name user.warn klogd: Code: e91ba800 e3a0b000
(e7ffdefe) e1a0100d e0812100
#

Thanks in advance for any help,

Dmytro

Re: How to configure gdb on arm-linux (for CDB89712)

[Daniel Jacobowitz]

On Fri, Feb 07, 2003 at 11:40:40PM +1300, Dmytro Bablinyuk wrote:
> I built arm-linux and put it on the board. Also I built a cross-compiler 
> (using uclibc)

> On host:
> 
> [Dmytro@sardine Dmytro]$ arm-gdb -nw
> $ARM_ROOT/ramdisk/target/armdevelop/hello
> GNU gdb 5.2.1
> Copyright 2002 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=i686-pc-linux-gnu
> --target=arm-linux"...
> (gdb) target remote 172.25.193.23:1023
> Remote debugging using 172.25.193.23:1023
> 0x00008110 in _start ()
> (gdb) b main
> Breakpoint 1 at 0x8158: file hello.c, line 4.
> (gdb) c
> Continuing.
> 
> Program received signal SIGILL, Illegal instruction.
> 0x00008114 in _start ()
> (gdb)
> 
> 
> On target(CDB89712)
> 
> # gdbserver 172.25.140.19:1023 /armdevelop/hello
> Process /armdevelop/hello created; pid = 196
> Remote debugging from host 172.25.140.19
> hello(135): undefined instruction: pc=00008114
> Code: e91ba800 e3a0b000 (e7ffdefe) e1a0100d e0812100
> Killing inferior
> #

This is a known problem between GDB 5.3 and uclibc: uclibc doesn't
leave the identifying marks that GDB uses to figure out that something
is a "Linux" binary rather than a "generic ELF" binary.  Try a CVS
snapshot of GDB and I bet it'll work.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: How to configure gdb on arm-linux (for CDB89712)

[Erik Andersen]

On Fri, 7 Feb 2003 08:27:41 -0500, Daniel Jacobowitz wrote:
> This is a known problem between GDB 5.3 and uclibc: uclibc
> doesn't leave the identifying marks that GDB uses to figure out
> that something is a "Linux" binary rather than a "generic ELF"
> binary.  Try a CVS snapshot of GDB and I bet it'll work.

I've just added the .note.ABI-tag section to uClibc's crt0.o
and crt1.o for arm, which lets gdb 5.3 now behave itself when
debugging uClibc binaries on arm.  I just tried it, and it
worked as expected -- no more SIGILLs...

Daniel -- is arm the only architecture for which the
.note.ABI-tag section is required for proper gdb behavior?

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: How to configure gdb on arm-linux (for CDB89712)

[Daniel Jacobowitz]

On Sat, Feb 08, 2003 at 03:36:36AM -0700, Erik Andersen wrote:
> On Fri, 7 Feb 2003 08:27:41 -0500, Daniel Jacobowitz wrote:
> > This is a known problem between GDB 5.3 and uclibc: uclibc
> > doesn't leave the identifying marks that GDB uses to figure out
> > that something is a "Linux" binary rather than a "generic ELF"
> > binary.  Try a CVS snapshot of GDB and I bet it'll work.
> 
> I've just added the .note.ABI-tag section to uClibc's crt0.o
> and crt1.o for arm, which lets gdb 5.3 now behave itself when
> debugging uClibc binaries on arm.  I just tried it, and it
> worked as expected -- no more SIGILLs...

Note that the next release will behave OK even without it, I tink.

> Daniel -- is arm the only architecture for which the
> .note.ABI-tag section is required for proper gdb behavior?

I don't know offhand; really, it affects all of them, but ARM is just
the most visible failure.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: How to configure gdb on arm-linux (for CDB89712)

[Daniel Jacobowitz]

On Tue, Feb 11, 2003 at 12:50:30PM +1300, Dmytro Bablinyuk wrote:
> Right now (when I recompiled gdb 5.3 with new uClibc), it's strange, I 
> don't have set/show osabi command available anymore.
> Is it something wrong (I can debug remote application with no problem)?

They're in GDB CVS, not in 5.3 (they're pretty new).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: How to configure gdb on arm-linux (for CDB89712)

[Dmytro Bablinyuk]

 >
 >
 >On Sat, Feb 08, 2003 at 02:38:21PM +1300, Dmytro Bablinyuk wrote:
 >
 >
 >>>
 >>>
 >>>>>On host:
 >>>>>
 >>>>>This GDB was configured as "--host=i686-pc-linux-gnu
 >>>>>--target=arm-linux"...
 >>>>>(gdb) target remote 172.25.193.23:1023
 >>>>>Remote debugging using 172.25.193.23:1023
 >>>>>0x00008110 in _start ()
 >>>>>(gdb) b main
 >>>>>Breakpoint 1 at 0x8158: file hello.c, line 4.
 >>>>>(gdb) c
 >>>>>Continuing.
 >>>>>
 >>>>>Program received signal SIGILL, Illegal instruction.
 >>>>>0x00008114 in _start ()
 >>>>>(gdb)
 >>>>>
 >>>>>
 >>>>>On target(CDB89712)
 >>>>>
 >>>>># gdbserver 172.25.140.19:1023 /armdevelop/hello
 >>>>>Process /armdevelop/hello created; pid = 196
 >>>>>Remote debugging from host 172.25.140.19
 >>>>>hello(135): undefined instruction: pc=00008114
 >>>>>Code: e91ba800 e3a0b000 (e7ffdefe) e1a0100d e0812100
 >>>>>Killing inferior
 >>>>>#
 >>>>>
 >>>>>
 >>>>This is a known problem between GDB 5.3 and uclibc: uclibc doesn't
 >>>>leave the identifying marks that GDB uses to figure out that something
 >>>>is a "Linux" binary rather than a "generic ELF" binary.  Try a CVS
 >>>>snapshot of GDB and I bet it'll work.
 >>>>
 >>>>
 >>>Thank you Daniel,
 >>>
 >>>I got a CVS snapshot and I have a little different result now.
 >>>I tried to compile it the same way (arm-linux) and using
 >>>armv4l-unknown-linux option but in both cases result was the same
 >>>"Segmentation fault"
 >>>Below I attached a debug output from gdb and gdbserver.
 >>>May be I am doing something plainly wrong?
 >>>Another interesting detail I noticed - in previous version I had
 >>>0x00008110 in _start () in this version 0x40000d20 in ?? ().
 >>>
 >>>
 >>>
 >>I have discovered that if you try to continue wihout breakpoint it sends
 >>a messages:
 >>
 >>(gdb) c
 >>Continuing.
 >>Sending packet: $Z0,8110,4#e0...Ack
 >>Packet received:
 >>Packet Z0 (software-breakpoint) is NOT supported
 >>Sending packet: $m8110,4#97...Ack
 >>Packet received: 03000000
 >>target_xfer_memory (0x8110, xxx, 4, read, xxx) = 4, bytes = 03 00 00 00
 >>Sending packet: $X8110,0:#b8...Ack
 >>Packet received:
 >>binary downloading NOT suppported by target
 >>Sending packet: $M8110,4:fedeffe7#ad...Ack  << write mem at 0x8110, 4
 >>bytes, fedeffe7 - this fails on target!!
 >>Packet received: OK
 >>target_xfer_memory (0x8110, xxx, 4, write, xxx) = 4, bytes =
 >>fe de ff e7
 >>target_insert_breakpoint (0x8110, xxx) = 0
 >>...
 >>
 >>On target this looks like:
 >>
 >>Jan  1 00:45:29 name user.debug klogd: hello: unhandled page fault at
 >>pc=0x40003148, lr=0xe7ffdefe (bad address=0x7ffe7118, code 0)
 >>
 >>According to http://sources.redhat.com/ml/gdb/2002-08/msg00141.html
 >>
 >>$M8110,4:fedeffe7 - "That's not an arm-linux breakpoint, it's an ARM
 >>breakpoint. That's why it isn't working."
 >>
 >>I tried to play with set architecture and set osabi but without any luck.
 >>
 >>Daniel, you were in that discussion
 >>(http://sources.redhat.com/ml/gdb/2002-08/msg00141.html) - is there any
 >>other ways to tell GDB to recognise uClibc binaries?
 >>
 >>
 >
 >That's not the problem you're having... you need to figure out why
 >a write to 0x8110 is causing a fault at 0x7ffe7118.  I imagine that's
 >your problem.
 >
 >Meanwhile, if it's using the wrong breakpoint, what does "show osabi"
 >say after you're connected?
 >
 >
Thank you Daniel,

The problem was resolved from uClibc side, see
http://www.uclibc.org/lists/uclibc/2003-February/007814.html

Right now (when I recompiled gdb 5.3 with new uClibc), it's strange, I 
don't have set/show osabi command available anymore.
Is it something wrong (I can debug remote application with no problem)?

Re: How to configure gdb on arm-linux (for CDB89712)

[Daniel Jacobowitz]

On Sat, Feb 08, 2003 at 02:38:21PM +1300, Dmytro Bablinyuk wrote:
> >
> >
> >>>On host:
> >>>
> >>>This GDB was configured as "--host=i686-pc-linux-gnu
> >>>--target=arm-linux"...
> >>>(gdb) target remote 172.25.193.23:1023
> >>>Remote debugging using 172.25.193.23:1023
> >>>0x00008110 in _start ()
> >>>(gdb) b main
> >>>Breakpoint 1 at 0x8158: file hello.c, line 4.
> >>>(gdb) c
> >>>Continuing.
> >>>
> >>>Program received signal SIGILL, Illegal instruction.
> >>>0x00008114 in _start ()
> >>>(gdb)
> >>>
> >>>
> >>>On target(CDB89712)
> >>>
> >>># gdbserver 172.25.140.19:1023 /armdevelop/hello
> >>>Process /armdevelop/hello created; pid = 196
> >>>Remote debugging from host 172.25.140.19
> >>>hello(135): undefined instruction: pc=00008114
> >>>Code: e91ba800 e3a0b000 (e7ffdefe) e1a0100d e0812100
> >>>Killing inferior
> >>>#
> >>
> >>
> >>This is a known problem between GDB 5.3 and uclibc: uclibc doesn't
> >>leave the identifying marks that GDB uses to figure out that something
> >>is a "Linux" binary rather than a "generic ELF" binary.  Try a CVS
> >>snapshot of GDB and I bet it'll work.
> >
> >
> >Thank you Daniel,
> >
> >I got a CVS snapshot and I have a little different result now.
> >I tried to compile it the same way (arm-linux) and using 
> >armv4l-unknown-linux option but in both cases result was the same 
> >"Segmentation fault"
> >Below I attached a debug output from gdb and gdbserver.
> >May be I am doing something plainly wrong?
> >Another interesting detail I noticed - in previous version I had 
> >0x00008110 in _start () in this version 0x40000d20 in ?? ().
> >
> I have discovered that if you try to continue wihout breakpoint it sends 
> a messages:
> 
> (gdb) c
> Continuing.
> Sending packet: $Z0,8110,4#e0...Ack
> Packet received:
> Packet Z0 (software-breakpoint) is NOT supported
> Sending packet: $m8110,4#97...Ack        
> Packet received: 03000000
> target_xfer_memory (0x8110, xxx, 4, read, xxx) = 4, bytes = 03 00 00 00
> Sending packet: $X8110,0:#b8...Ack       
> Packet received:
> binary downloading NOT suppported by target
> Sending packet: $M8110,4:fedeffe7#ad...Ack  << write mem at 0x8110, 4 
> bytes, fedeffe7 - this fails on target!!
> Packet received: OK
> target_xfer_memory (0x8110, xxx, 4, write, xxx) = 4, bytes =
> fe de ff e7
> target_insert_breakpoint (0x8110, xxx) = 0
> ...
> 
> On target this looks like:
> 
> Jan  1 00:45:29 name user.debug klogd: hello: unhandled page fault at 
> pc=0x40003148, lr=0xe7ffdefe (bad address=0x7ffe7118, code 0)
> 
> According to http://sources.redhat.com/ml/gdb/2002-08/msg00141.html
> 
> $M8110,4:fedeffe7 - "That's not an arm-linux breakpoint, it's an ARM 
> breakpoint. That's why it isn't working."
> 
> I tried to play with set architecture and set osabi but without any luck.
> 
> Daniel, you were in that discussion 
> (http://sources.redhat.com/ml/gdb/2002-08/msg00141.html) - is there any 
> other ways to tell GDB to recognise uClibc binaries?

That's not the problem you're having... you need to figure out why
a write to 0x8110 is causing a fault at 0x7ffe7118.  I imagine that's
your problem.

Meanwhile, if it's using the wrong breakpoint, what does "show osabi"
say after you're connected?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: How to configure gdb on arm-linux (for CDB89712)

[Dmytro Bablinyuk]

>
>
>>> On host:
>>>
>>> This GDB was configured as "--host=i686-pc-linux-gnu
>>> --target=arm-linux"...
>>> (gdb) target remote 172.25.193.23:1023
>>> Remote debugging using 172.25.193.23:1023
>>> 0x00008110 in _start ()
>>> (gdb) b main
>>> Breakpoint 1 at 0x8158: file hello.c, line 4.
>>> (gdb) c
>>> Continuing.
>>>
>>> Program received signal SIGILL, Illegal instruction.
>>> 0x00008114 in _start ()
>>> (gdb)
>>>
>>>
>>> On target(CDB89712)
>>>
>>> # gdbserver 172.25.140.19:1023 /armdevelop/hello
>>> Process /armdevelop/hello created; pid = 196
>>> Remote debugging from host 172.25.140.19
>>> hello(135): undefined instruction: pc=00008114
>>> Code: e91ba800 e3a0b000 (e7ffdefe) e1a0100d e0812100
>>> Killing inferior
>>> #
>>
>>
>> This is a known problem between GDB 5.3 and uclibc: uclibc doesn't
>> leave the identifying marks that GDB uses to figure out that something
>> is a "Linux" binary rather than a "generic ELF" binary.  Try a CVS
>> snapshot of GDB and I bet it'll work.
>
>
> Thank you Daniel,
>
> I got a CVS snapshot and I have a little different result now.
> I tried to compile it the same way (arm-linux) and using 
> armv4l-unknown-linux option but in both cases result was the same 
> "Segmentation fault"
> Below I attached a debug output from gdb and gdbserver.
> May be I am doing something plainly wrong?
> Another interesting detail I noticed - in previous version I had 
> 0x00008110 in _start () in this version 0x40000d20 in ?? ().
>
I have discovered that if you try to continue wihout breakpoint it sends 
a messages:

(gdb) c
Continuing.
Sending packet: $Z0,8110,4#e0...Ack
Packet received:
Packet Z0 (software-breakpoint) is NOT supported
Sending packet: $m8110,4#97...Ack        
Packet received: 03000000
target_xfer_memory (0x8110, xxx, 4, read, xxx) = 4, bytes = 03 00 00 00
Sending packet: $X8110,0:#b8...Ack       
Packet received:
binary downloading NOT suppported by target
Sending packet: $M8110,4:fedeffe7#ad...Ack  << write mem at 0x8110, 4 
bytes, fedeffe7 - this fails on target!!
Packet received: OK
target_xfer_memory (0x8110, xxx, 4, write, xxx) = 4, bytes =
 fe de ff e7
target_insert_breakpoint (0x8110, xxx) = 0
...

On target this looks like:

Jan  1 00:45:29 name user.debug klogd: hello: unhandled page fault at 
pc=0x40003148, lr=0xe7ffdefe (bad address=0x7ffe7118, code 0)

According to http://sources.redhat.com/ml/gdb/2002-08/msg00141.html

$M8110,4:fedeffe7 - "That's not an arm-linux breakpoint, it's an ARM 
breakpoint. That's why it isn't working."

I tried to play with set architecture and set osabi but without any luck.

Daniel, you were in that discussion 
(http://sources.redhat.com/ml/gdb/2002-08/msg00141.html) - is there any 
other ways to tell GDB to recognise uClibc binaries?

Re: How to configure gdb on arm-linux (for CDB89712)

[Dmytro Bablinyuk]

>> On host:
>>
>> This GDB was configured as "--host=i686-pc-linux-gnu
>> --target=arm-linux"...
>> (gdb) target remote 172.25.193.23:1023
>> Remote debugging using 172.25.193.23:1023
>> 0x00008110 in _start ()
>> (gdb) b main
>> Breakpoint 1 at 0x8158: file hello.c, line 4.
>> (gdb) c
>> Continuing.
>>
>> Program received signal SIGILL, Illegal instruction.
>> 0x00008114 in _start ()
>> (gdb)
>>
>>
>> On target(CDB89712)
>>
>> # gdbserver 172.25.140.19:1023 /armdevelop/hello
>> Process /armdevelop/hello created; pid = 196
>> Remote debugging from host 172.25.140.19
>> hello(135): undefined instruction: pc=00008114
>> Code: e91ba800 e3a0b000 (e7ffdefe) e1a0100d e0812100
>> Killing inferior
>> #
>
>
>
> This is a known problem between GDB 5.3 and uclibc: uclibc doesn't
> leave the identifying marks that GDB uses to figure out that something
> is a "Linux" binary rather than a "generic ELF" binary.  Try a CVS
> snapshot of GDB and I bet it'll work.


Thank you Daniel,

I got a CVS snapshot and I have a little different result now.
I tried to compile it the same way (arm-linux) and using 
armv4l-unknown-linux option but in both cases result was the same 
"Segmentation fault"
Below I attached a debug output from gdb and gdbserver.
May be I am doing something plainly wrong?
Another interesting detail I noticed - in previous version I had 
0x00008110 in _start () in this version 0x40000d20 in ?? ().

On host:

[root@sardine gdbserver]# arm-gdb -nw 
/home/Dmytro/Dev/armlinux/ramdisk/target/armdevelop/hello
GNU gdb 2003-02-07-cvs
Copyright 2003 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=i686-pc-linux-gnu 
--target=armv4l-unknown-linux"...
(gdb) set debug remote 1
(gdb) set debug target 1
(gdb) target remote marin:1023
Remote debugging using marin:1023
Sending packet: $Hc-1#09...Ack
Packet received: OK
Sending packet: $qC#b4...Ack
Packet received:
Sending packet: $qOffsets#4b...Ack
Packet received:
Sending packet: $?#3f...Ack
Packet received: T050b:00000000;0d:e0feffbf;0f:200d0040;
target_wait (-1, status) = 42000,   status->kind = stopped, signal = 
SIGTRAP
Sending packet: $m40000d20,4#87...Ack
Packet received: 0d70a0e1
target_xfer_memory (0x40000d20, xxx, 4, read, xxx) = 4, bytes = 0d 70 a0 e1
Sending packet: $Hg0#df...Ack
Packet received: OK
Sending packet: $g#67...Ack
Packet received: 
0000000085ffffbf0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e0feffbf00000000200d00400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000 

target_fetch_registers (cpsr) = 10000000 0x10 16
target_terminal_ours ()
0x40000d20 in ?? ()
Sending packet: $qSymbol::#5b...Ack
Packet received: OK
Packet qSymbol (symbol-lookup) is supported
(gdb) b main
Breakpoint 1 at 0x8158: file hello.c, line 4.
(gdb) c
Continuing.
Sending packet: $Z0,8110,4#e0...Ack
Packet received:
Packet Z0 (software-breakpoint) is NOT supported
Sending packet: $m8110,4#97...Ack
Packet received: 03000000
target_xfer_memory (0x8110, xxx, 4, read, xxx) = 4, bytes =
03 00 00 00
Sending packet: $X8110,0:#b8...Ack
Packet received:
binary downloading NOT suppported by target
Sending packet: $M8110,4:fedeffe7#ad...Ack
Packet received: OK
target_xfer_memory (0x8110, xxx, 4, write, xxx) = 4, bytes =
fe de ff e7
target_insert_breakpoint (0x8110, xxx) = 0
Sending packet: $m8158,4#a3...Ack
Packet received: 12000000
target_xfer_memory (0x8158, xxx, 4, read, xxx) = 4, bytes = 12 00 00 00
Sending packet: $M8158,4:fedeffe7#b9...Ack
Packet received: OK
target_xfer_memory (0x8158, xxx, 4, write, xxx) = 4, bytes =
fe de ff e7
target_insert_breakpoint (0x8158, xxx) = 0
target_terminal_inferior ()
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack
target_resume (-1, continue, 0)
Packet received: T0b0b:e8f8ffbf;0d:90f8ffbf;0f:58310040;
target_wait (-1, status) = 42000,   status->kind = stopped, signal = 
SIGSEGV
target_terminal_ours_for_output ()

Program received signal SIGSEGV, Segmentation fault.
Sending packet: $m40003158,4#62...Ack
Packet received: 0120dce4
target_xfer_memory (0x40003158, xxx, 4, read, xxx) = 4, bytes = 01 20 dc e4
Sending packet: $g#67...Ack
Packet received: 
745100401040014028820000fedeffe7acf8ffbfacf8ffbf388100000000000000000000000000001ccd0040e8f8ffbf266100e890f8ffbf02000000583100400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000020 

target_fetch_registers (cpsr) = 10000020 0x20000010 536870928
Sending packet: $m40003158,4#62...Ack
Packet received: 0120dce4
target_xfer_memory (0x40003158, xxx, 4, read, xxx) = 4, bytes = 01 20 dc e4
Sending packet: $mbffff8e8,4#9c...Ack
Packet received: fc2f0040
target_xfer_memory (0xbffff8e8, xxx, 4, read, xxx) = 4, bytes = fc 2f 00 40
Sending packet: $m40002ff4,4#c3...Ack
Packet received: 04b04ce2
target_xfer_memory (0x40002ff4, xxx, 4, read, xxx) = 4, bytes = 04 b0 4c e2
Sending packet: $m40002ff8,4#c7...Ack
Packet received: 30d04de2
target_xfer_memory (0x40002ff8, xxx, 4, read, xxx) = 4, bytes = 30 d0 4d e2
Sending packet: $m40002ffc,4#f2...Ack
Packet received: 40000be5
target_xfer_memory (0x40002ffc, xxx, 4, read, xxx) = 4, bytes = 40 00 0b e5
Sending packet: $m40003000,4#54...Ack
Packet received: 44300be5
target_xfer_memory (0x40003000, xxx, 4, read, xxx) = 4, bytes = 44 30 0b e5
Sending packet: $m40003004,4#58...Ack
Packet received: 0140a0e1
target_xfer_memory (0x40003004, xxx, 4, read, xxx) = 4, bytes = 01 40 a0 e1
Sending packet: $m40003008,4#5c...Ack
Packet received: cca29fe5
target_xfer_memory (0x40003008, xxx, 4, read, xxx) = 4, bytes = cc a2 9f e5
Sending packet: $m4000300c,4#87...Ack
Packet received: 0280a0e1
target_xfer_memory (0x4000300c, xxx, 4, read, xxx) = 4, bytes = 02 80 a0 e1
Sending packet: $m40003010,4#55...Ack
Packet received: 0aa08fe0
target_xfer_memory (0x40003010, xxx, 4, read, xxx) = 4, bytes = 0a a0 8f e0
Sending packet: $m40003014,4#59...Ack
Packet received: 05f7ffeb
target_xfer_memory (0x40003014, xxx, 4, read, xxx) = 4, bytes = 05 f7 ff eb
Sending packet: $m40003018,4#5d...Ack
Packet received: 0030a0e3
target_xfer_memory (0x40003018, xxx, 4, read, xxx) = 4, bytes = 00 30 a0 e3
Sending packet: $m4000301c,4#88...Ack
Packet received: 54300be5
target_xfer_memory (0x4000301c, xxx, 4, read, xxx) = 4, bytes = 54 30 0b e5
Sending packet: $m40003020,4#56...Ack
Packet received: b8229fe5
target_xfer_memory (0x40003020, xxx, 4, read, xxx) = 4, bytes = b8 22 9f e5
Sending packet: $m40003024,4#5a...Ack
Packet received: 58200be5
target_xfer_memory (0x40003024, xxx, 4, read, xxx) = 4, bytes = 58 20 0b e5
Sending packet: $m40003028,4#5e...Ack
Packet received: 54901be5
target_xfer_memory (0x40003028, xxx, 4, read, xxx) = 4, bytes = 54 90 1b e5
Sending packet: $m4000302c,4#89...Ack
Packet received: 02309ae7
target_xfer_memory (0x4000302c, xxx, 4, read, xxx) = 4, bytes = 02 30 9a e7
Sending packet: $m40003030,4#57...Ack
Packet received: 44201be5
target_xfer_memory (0x40003030, xxx, 4, read, xxx) = 4, bytes = 44 20 1b e5
target_terminal_ours ()
frame.c:1439: internal-error: deprecated_update_frame_pc_hack: Assertion 
`frame->next != NULL' failed.
A problem internal to GDB has been detected.  Further
debugging may prove unreliable.
Quit this debugging session? (y or n) n
Create a core file of GDB? (y or n) y
Sending packet: $M8110,4:03000000#34...Ack
Packet received: OK
target_xfer_memory (0x8110, xxx, 4, write, xxx) = 4, bytes =
03 00 00 00
target_remove_breakpoint (0x8110, xxx) = 0
Sending packet: $M8158,4:12000000#40...Ack
Packet received: OK
target_xfer_memory (0x8158, xxx, 4, write, xxx) = 4, bytes = 12 00 00 00
target_remove_breakpoint (0x8158, xxx) = 0
target_terminal_ours ()
0x40003158 in ?? ()
(gdb) n
target_terminal_ours ()
Cannot find bounds of current function
(gdb) quit
The program is running.  Exit anyway? (y or n) y
Sending packet: $k#6b...Ack
target_mourn_inferior ()
target_kill ()
[root@sardine gdbserver]#

On target:

# gdbserver 172.25.140.19:1023 /armdevelop/hello
Process /armdevelop/hello created; pid = 43
Remote debugging from host 172.25.140.19
Killing inferior
# tail /var/log/messages
Jan  1 00:00:33 name user.info klogd: eth0: using half-duplex 10Base-T 
(RJ-45)
Jan  1 00:20:33 name syslog.info -- MARK --
Jan  1 00:32:35 name user.debug klogd: hello: unhandled page fault at 
pc=0x40003158, lr=0x00000002 (bad address=0xe8006126, code 0)
Jan  1 00:33:51 name user.debug klogd: hello: unhandled page fault at 
pc=0x40003158, lr=0x00000002 (bad address=0xe8006126, code 0)
Jan  1 00:40:33 name syslog.info -- MARK --
Jan  1 00:40:36 name user.debug klogd: hello: unhandled page fault at 
pc=0x40003158, lr=0x00000002 (bad address=0xe8006126, code 0)
Jan  1 00:48:54 name user.debug klogd: hello: unhandled page fault at 
pc=0x40003148, lr=0xe7ffdefe (bad address=0x7ffe7118, code 0)
Jan  1 00:59:59 name user.debug klogd: hello: unhandled page fault at 
pc=0x40003158, lr=0x00000002 (bad address=0xe8006126, code 0)
Jan  1 01:00:33 name syslog.info -- MARK --
Jan  1 01:08:55 name user.debug klogd: hello: unhandled page fault at 
pc=0x40003158, lr=0x00000002 (bad address=0xe8006126, code 0)
#

-- 
Dmytro Bablinyuk
Design Engineer                  Phone: (64)(3) 358 0307
Tait Electronics                 Fax  : (64)(3) 359 4632
PO Box 1645 Christchurch        
New Zealand