From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12278 invoked by alias); 10 Feb 2003 23:50:35 -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 12269 invoked from network); 10 Feb 2003 23:50:34 -0000 Received: from unknown (HELO gatekeeper.tait.co.nz) (202.37.96.11) by 172.16.49.205 with SMTP; 10 Feb 2003 23:50:34 -0000 Received: from gatekeeper.tait.co.nz (localhost.localdomain [127.0.0.1]) by gatekeeper.tait.co.nz (8.11.2/8.9.3) with ESMTP id h1ANoVP23910 for ; Tue, 11 Feb 2003 12:50:31 +1300 Received: from sunstorm.tait.co.nz (sunstorm.tait.co.nz [172.25.40.9]) by gatekeeper.tait.co.nz (8.11.2/8.9.3) with ESMTP id h1ANoUN23900; Tue, 11 Feb 2003 12:50:30 +1300 Received: from tait.co.nz (sardine.tait.co.nz [172.25.140.19]) by sunstorm.tait.co.nz (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0HA40016QA86D4@sunstorm.tait.co.nz>; Tue, 11 Feb 2003 12:50:30 +1300 (NZDT) Date: Mon, 10 Feb 2003 23:50:00 -0000 From: Dmytro Bablinyuk Subject: Re: How to configure gdb on arm-linux (for CDB89712) To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Message-id: <3E483AC6.4070007@tait.co.nz> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 References: <3E4434CA.5070001@tait.co.nz> <3E445F8D.5050808@tait.co.nz> <20030210203109.GA18397@nevyn.them.org> X-SW-Source: 2003-02/txt/msg00186.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? > > 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)?