From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2406 invoked by alias); 3 Sep 2004 12:37:06 -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 2397 invoked from network); 3 Sep 2004 12:37:04 -0000 Received: from unknown (HELO miranda.se.axis.com) (193.13.178.2) by sourceware.org with SMTP; 3 Sep 2004 12:37:04 -0000 Received: from [10.84.130.1] (ironmaiden.se.axis.com [10.84.130.1]) by miranda.se.axis.com (8.12.9/8.12.9/Debian-5local0.1) with ESMTP id i83Cb305025138 for ; Fri, 3 Sep 2004 14:37:03 +0200 Message-ID: <4138656F.9020001@axis.com> Date: Fri, 03 Sep 2004 12:37:00 -0000 From: Orjan Friberg Organization: Axis Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: Register fudging (CRISv32) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-09/txt/msg00031.txt.bz2 My upcoming CRISv32 port (remote target, Linux based) is starting to look pretty good(*) but I'm left with a nagging feeling that the register fudging I'm doing isn't necessarily done where it should be and/or the right way. Right now it's being done in three different places (this relating to debugging user-mode programs): (1) in the kernel (2) in the Gdbserver (3) in GDB Basically, what I would like to hear is people's opinions on how various kinds of register fudging should be done. On to the details: * The first fudging is the equivalent to DECR_PC_AFTER_BREAK, though it's not using that mechanism in GDB; instead it's being done in the kernel. On one hand I feel more comfortable doing it in the kernel where I know exactly what happens; on the other hand the decrementation needs to be duplicated in, for example, a classic kernel gdb stub. Should I be using DECR_PC_AFTER_BREAK in GDB instead? Or the implementation in the Gdbserver? * Another fudging that takes place is the filling in of a pseudo-PC register (there is no actual PC register, so it's not present in struct pt_regs). This is being done in the Gdbserver. In addition, in case we stopped in a delay slot, I *may* need to look at the code to determine what the PC should be set to (meaning I can't rely on register contents alone). I've found 3 cases where this needs to be done: (1) In case of a stop (break, h/w watchpoint, receiving a signal etc) (2) When unwinding a sigtramp frame (3) When loading a core dump (supply_gregset) As of now, delay-slot-adjustment of the PC is only being done for the first case (normal stop), and it's also done in the Gdbserver. The other two cases don't handle being stopped in a delay slot yet, though I have a hunch this could be done in GDB. * In addition to this, I need to set the h/w single-step PC to 0 in the kernel at various times, but I've seen other architectures doing that and I feel pretty confident that is the right way to do it. Thanks for any insights. (*) the gdb.base testsuite results in about 6050 PASS and around 20 FAIL (the relatively new sigbpt.exp, siginfo.exp, signull.exp, and sigstep.exp are all PASS - yay!) -- Orjan Friberg Axis Communications