From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14882 invoked by alias); 20 Feb 2003 04:39:30 -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 14872 invoked from network); 20 Feb 2003 04:39:29 -0000 Received: from unknown (HELO TYO201.gate.nec.co.jp) (210.143.35.51) by 172.16.49.205 with SMTP; 20 Feb 2003 04:39:29 -0000 Received: from mailgate4.nec.co.jp ([10.7.69.193]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id h1K4dRw21410; Thu, 20 Feb 2003 13:39:27 +0900 (JST) Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id h1K4dQ521785; Thu, 20 Feb 2003 13:39:26 +0900 (JST) Received: from mcsss2.ucom.lsi.nec.co.jp ([10.30.114.133]) by mailsv.nec.co.jp (8.11.6/3.7W-MAILSV-NEC) with ESMTP id h1K4dPq09157; Thu, 20 Feb 2003 13:39:25 +0900 (JST) Received: from mcspd15.ucom.lsi.nec.co.jp (mcspd15 [10.30.114.174]) by mcsss2.ucom.lsi.nec.co.jp (8.10.2+Sun/3.7Wlsi_mx_6.0) with ESMTP id h1K4dPB23623; Thu, 20 Feb 2003 13:39:25 +0900 (JST) Received: by mcspd15.ucom.lsi.nec.co.jp (Postfix, from userid 31295) id 789BE3728; Thu, 20 Feb 2003 13:39:25 +0900 (JST) To: gdb@sources.redhat.com Subject: emulating single-step in gdbserver? Reply-To: Miles Bader System-Type: i686-pc-linux-gnu Blat: Foop From: Miles Bader Date: Thu, 20 Feb 2003 04:39:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-02/txt/msg00395.txt.bz2 Hi, I'm porting gdbserver to uClinux on the (NEC) v850e processor, and ptrace on this machine doesn't support PTRACE_SINGLESTEP (because the hardware doesn't support single-stepping). I thought gdb might already support an emulated singlestep by always setting a temporary breakpoint at the next insn, but from a quick perusal of the source, it seems not. So I'm wondering where the best place to stick this functionality is. My thought is to modify `linux_resume_one_process', in gdbserver/linux-low.c, something like this (error-checking omitted): static void linux_resume_one_process (struct inferior_list_entry *entry, int step, int signal) { ... #ifdef PTRACE_SINGLESTEP ptrace(step ? PTRACE_SINGLESTEP : PTRACE_CONT, process->lwpid, 0, signal); #else if (step) /* This platform can't single-step, so simulate it. */ { CORE_ADDR stop_pc = (*the_low_target.get_pc) (); if (! (*the_low_target.breakpoint_at) (stop_pc)) { CORE_ADDR next_pc = (*the_low_target.next_pc) (); set_breakpoint_at (next_pc, delete_single_step_breakpoint); } } ptrace (PTRACE_CONT, process->lwpid, 0, signal); #endif ... } void delete_single_step_breakpoint (CORE_ADDR stopped_at) { struct breakpoint *bp = find_breakpoint_at (stopped_at); if (bp) delete_breakpoint (bp); else error ("Could not find single-step breakpoint in list."); } The `next_pc' member added to the_low_target would be a function that calculates the next pc after executing the current insn. Any comments on this approach; does it seem correct? An alternative might be to add this to the kernel's ptrace implementation; however, I'd rather not do this, as the `calculate the next insn' function is a little hairy, and I'd rather it be in user-space. A related question, BTW, is what's the precise meaning of `the_low_target.breakpoint_reinsert_addr'? It's not documented very well... Thanks, -Miles p.s. Does anyone know if the gdb GNATS database is really the best place to send bug-fix patches? I sent something there a few months ago, and it's languished ever since, with no feedback, no change of state, no nothing. The patch only affects the NEC v850, and is certainly an improvement over the existing code (which is very clearly wrong). Would it be better to send email to gdb-patches or something? -- I'd rather be consing.