From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: Andrew Cagney Cc: gdb@sourceware.cygnus.com Subject: Re: remote protocol extension for step out of range Date: Wed, 21 Feb 2001 14:17:00 -0000 Message-id: <5mlmqzu1el.fsf@jtc.redback.com> References: <5mwvbjj7k8.fsf@jtc.redback.com> <5mvgqw8hpt.fsf@jtc.redback.com> <3A79BFB3.E2C17712@cygnus.com> <5mpuh2unuq.fsf@jtc.redback.com> <3A7EED79.678DFCE4@cygnus.com> <5mhf2899s7.fsf@jtc.redback.com> <3A90A01E.8DEF5998@cygnus.com> X-SW-Source: 2001-02/msg00282.html >>>>> "Andrew" == Andrew Cagney writes: >> I think we can poke a similar hole in GDB as it stands today. For >> instance, GDB does a step out of range for thread T1. Without the >> step out of range command, it does it internally by issuing multiple >> steps and comparing the PC after each step. While this is happening, >> thread T2 hits a breakpoint and returns status that T2 has stopped. >> The user then does a step out of range for T2. >> >> I think the problem is the same, and will only be solved when GDB >> is able to track multiple processes/threads/contexts. Andrew> That is what I want to be 100% clear on. Andrew> Andrew> It means that there is probably going to be an interum version Andrew> of this feature - one that works with the current thread Andrew> model. This discussion thread [er, groan] should provide the Andrew> rationale behind the decision :-) I think it's more like this feature will always work in a single threaded context, and because of current limitations within GDB will "mostly" work in a multi-threaded context. It will fail if there is a context switch in the middle of a step over range. This same failure can occur without the step-over-range command when GDB issues multiple step-instruction commands and explicitly checks the pc to determine if it is in range. This problem will be addressed when GDB is enhanced to keep track of each execution context. I believe the protocol command itself is solid and won't need updating. If debug agents are written correctly, they will store the step ranges in thread specific instead of global variables. So they will not have to be updated. IMO there is a risk here. It would be best if we had a reference implementation, but as of yet we don't have a sample debug agent that supports threads. Something to address in the future. For the time being, it might be acceptable to mention this in the remote protocol section of the GDB User's manual. Is there anything else you think must be addressed? I'd like to make sure you're comfortable with this before going forward. On the other hand, I'd like to get this in because it makes debugging so much nicer over high latency links. --jtc -- J.T. Conklin RedBack Networks