This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

emulating single-step in gdbserver?


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)

     ptrace(step ? PTRACE_SINGLESTEP : PTRACE_CONT, process->lwpid, 0, signal);
     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);


   delete_single_step_breakpoint (CORE_ADDR stopped_at)
     struct breakpoint *bp = find_breakpoint_at (stopped_at);
     if (bp)
       delete_breakpoint (bp);
       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

A related question, BTW, is what's the precise meaning of
`the_low_target.breakpoint_reinsert_addr'?  It's not documented very



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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]