From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6822 invoked by alias); 27 Jun 2004 23:50:41 -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 6814 invoked from network); 27 Jun 2004 23:50:39 -0000 Received: from unknown (HELO gizmo08bw.bigpond.com) (144.140.70.18) by sourceware.org with SMTP; 27 Jun 2004 23:50:39 -0000 Received: (qmail 4073 invoked from network); 27 Jun 2004 23:37:06 -0000 Received: from unknown (HELO bwmam01.bigpond.com) (144.135.24.69) by gizmo08bw.bigpond.com with SMTP; 27 Jun 2004 23:37:06 -0000 Received: from cpe-203-51-249-49.qld.bigpond.net.au ([203.51.249.49]) by bwmam01.bigpond.com(MAM REL_3_4_2a 2/29004424) with SMTP id 29004424; Mon, 28 Jun 2004 09:50:37 +1000 Message-ID: <40DF5D4D.9060805@neurizon.net> Date: Sun, 27 Jun 2004 23:50:00 -0000 From: Steven Johnson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040115 MIME-Version: 1.0 To: Modi Banti CC: gdb@sources.redhat.com Subject: Re: Remote stub for ARM processor References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-06/txt/msg00267.txt.bz2 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 > > Thanks and regards, > Banti > > > >