Re: Separate 'continue' and 'step' handling from other remote packet handling

On 1/25/06, Amit Kale <amitkale@xxxxxxxxxxxxxx> wrote:
> This would be a great feature. I understand that much more work is going to be
> needed. For now improving single step and continue code is ok.
>
> I didn't understand why at_addr parameter is needed. Could you send us the
> outline of single-step, continue function calls from present stub code and
> future changes?

Did you see the comments in kgdb.h?  If they don't make it clear, I
need to improve them.
It's just because 'c' and 's' packets may contain an address to
continue at; if the address is missing, the PC is left alone.  Since
we're doing the parsing in core code now, we need some way to tell the
continue and step functions whether an address was given or not.

This part of the patch shows how it's used:

!                         /* try to read optional parameter, pc
!                          * unchanged if no parm */
!                         ptr = &remcom_in_buffer[1];
!                         length = kgdb_hex2long(&ptr, &addr);
!                         if (*ptr != '\0') {
!                                 error_packet (remcom_out_buffer, -EINVAL);
!                                 break;
!                         }
!
!                         if (remcom_in_buffer[0] == 'c')
!                                 kgdb_continue (linux_regs, length, addr);

Perhaps there should a separate 'set_resume_address' function instead,
to be called before kgdb_continue or kgdb_step?

> Ensuring that the code on other platforms doesn't break is essential. Perhaps
> you want to do it in small steps so that it's easier to verify each step.

That's a good idea; it's certainly how I've been developing the code so far.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642