From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18865 invoked by alias); 10 Feb 2003 20:31:19 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 18858 invoked from network); 10 Feb 2003 20:31:18 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 10 Feb 2003 20:31:18 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18iMTB-0008O3-00; Mon, 10 Feb 2003 16:32:09 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18iKa5-0004np-00; Mon, 10 Feb 2003 15:31:09 -0500 Date: Mon, 10 Feb 2003 20:31:00 -0000 From: Daniel Jacobowitz To: Dmytro Bablinyuk Cc: gdb@sources.redhat.com Subject: Re: How to configure gdb on arm-linux (for CDB89712) Message-ID: <20030210203109.GA18397@nevyn.them.org> Mail-Followup-To: Dmytro Bablinyuk , gdb@sources.redhat.com References: <3E4434CA.5070001@tait.co.nz> <3E445F8D.5050808@tait.co.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E445F8D.5050808@tait.co.nz> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-02/txt/msg00182.txt.bz2 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