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

[Dmytro Bablinyuk <dmytro dot bablinyuk at tait dot co dot 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)?