From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28544 invoked by alias); 28 Jun 2004 08:23:07 -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 28467 invoked from network); 28 Jun 2004 08:22:58 -0000 Received: from unknown (HELO sssup.it) (193.205.80.99) by sourceware.org with SMTP; 28 Jun 2004 08:22:58 -0000 Received: from [150.146.37.63] (account b.modi@sssup.it) by sssup.it (CommuniGate Pro WebUser 4.1.8) with HTTP id 4622147; Mon, 28 Jun 2004 10:39:25 +0200 From: "Modi Banti" Subject: Re: Remote stub for ARM processor To: Steven Johnson Cc: gdb@sources.redhat.com Date: Mon, 28 Jun 2004 14:03:00 -0000 Message-ID: In-Reply-To: <40DF5D4D.9060805@neurizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: 8bit X-SW-Source: 2004-06/txt/msg00271.txt.bz2 On Mon, 28 Jun 2004 09:50:37 +1000 Steven Johnson wrote: >Modi Banti wrote: > >> Hi, >> >> I am trying to buikd a remote stub for an ARM processor >>Simulator. I >> have couple of problems with this... >> >> 1) When a Simulator arrives at a breakpoint it sends the >>signal >> SIGTRAP 15 (register number): PC to GDB so the GDB stops >>and shows the >> instruction at PC but since for ARM processor PC point >>to current >> instruction + 8, so it shows me a wrong line. I am not >>sure while >> displaying the line GDB takes into account of Pipiline. >>I can overcome >> this problem tempararily by sending the signal SIGTRAP >>15: PC- 8. so >> it works correctly but I am not sure if this is the >>correct way of >> doing it. > >You have this problem with a simulator or the real ARM. > I believe you >have to adjust the PC, to point to the actual line >currently being >executed. I am not aware of any pipeline awareness in >GDB. This is a >particular quirk of the ARM, and is made worse by >Interrupts, where the >LR can have various offsets from the real return address, >depending on >the IRQ/branch/Arm/thumb mode in question. So trying to >find where you >came from can be problematic (not sure how GDB resolves >this when it >does a stack trace?) > >EG, LR after a BL = PC+4 in ARM, and PC+2 in thumb. but >FIQ LR = PC+4 >in both ARM and THUMB, but DABT LR = PC+8 for arm and >thumb. I believe >its up to the stub/simulator to deal with this quirk and >any problems it >might cause GDB's knowledge of the executing program, by >adjusting >accordingly. > >> >> 2) In reply to GDBs $s#73 (single step) command i send >>the same packet >> i.e SIGTRAP 15: PC - 8 . I am not sure if I need to send >>SIGTRAP or >> some other signal. Here also the 'n' command works >>prefectly fine with >> normal code but if it is a Function call then instead of >>stopping at >> next line GDB stops at line after that e. g for >>following code >> Mutex_lock(&mut); >> ++i; >> ++j; >> if I give 'n' command when GDB is at Mutex_lock(&mut) >>then it gives >> some series of $s#73 commands and finaly stops at ++j >>instead of >> stopping at ++i. this happens only in case of function >>call for normal >> statements it works perfectly fine. Here I am not sure >>whether SIGTRAP >> is a right signal and secondly sending PC -15 is correct >>or not ( if i >> send just PC here then insted og going to next >>instruction GDB steps >> in the function call). >> Can anybody help me with this or tell me which part of >>code in GDB >> handles this step instruction? > >n wont stop on the function call. It should stop on the >++i; the GDB >manual says about "next": > "This is similar to `step', but function calls that >appear > within the line of code are executed without >stopping. Execution > stops when control reaches a different line of code >at the > original stack level that was executing when you >gave the `next' > command." > >Im pretty sure the signal you send matters not in the >reply. > >Im sure you meant PC-8?? Maybe this has something to do >with LR? >because a function call will use LR? Maybe you need to >"adjust" LR as >well, depending on circumstances, otherwise LR wont point >to the ++i; it >will point to the ++j; (potentially confusing GDB if it >uses it). > >Sorry I cant be more helpful or categoric, we (my >company) are in the >process of writing a GDB target stub for ARM, id be >interested to know >how you fare with this problem. > >Steven Ok I got it working.....problem was GDB used to set a break point at next instruction after the function call and when stub informs GDB about break point it used to again issue $g# command and after looking at the contents of PC ( which was actual PC )it used to decide not to stop.... so here I always send PC - 8 ( depending on mode) and everything works correctly only drawback is when I say ' info Registers' instead of seeing the correct PC i see the adjusted PC ( I guess I have to live with it)