This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: How to configure gdb on arm-linux (for CDB89712)
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Dmytro Bablinyuk <dmytro dot bablinyuk at tait dot co dot nz>
- Cc: gdb at sources dot redhat dot com
- Date: Mon, 10 Feb 2003 15:31:09 -0500
- Subject: Re: How to configure gdb on arm-linux (for CDB89712)
- References: <3E4434CA.5070001@tait.co.nz> <3E445F8D.5050808@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?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer