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

[Dmytro Bablinyuk <dmytro.bablinyuk@tait.co.nz>]

 >
 >
 >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)?