From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: Andrew Cagney Cc: GDB Discussion Subject: Re: SOFTWARE_SINGLE_STEP_P and multi-arch Date: Tue, 05 Dec 2000 15:24:00 -0000 Message-id: <5mk89ezc2o.fsf@jtc.redback.com> References: <3A2C4141.B3C2F486@cygnus.com> X-SW-Source: 2000-12/msg00026.html >>>>> "Andrew" == Andrew Cagney writes: Andrew> At present there are two macros that control software stepping: Andrew> Andrew> SOFTWARE_SINGLE_STEP_P() Andrew> Andrew> and SOFTWARE_SINGLE_STEP(sig, insert_or_remove) Andrew> Andrew> I'd like to suggest the following: Andrew> Andrew> Rename SOFTWARE_SINGLE_STEP_P() to TARGET_SOFTWARE_SINGLE_STEP_P() and Andrew> add it to the *target* vector. You're correct that hardware single step support is target dependent. For example, SOFTWARE_SINGLE_STEP_P is 1 on the sparc (and thus the embedded sparc varients like the sparclite and sparclet), but single step performance using the remote protocol would be greatly improved if the stub managed the step internally. While not strictly a hard- ware single step, it acts more or less the same. Perhaps the names SOFTWARE_SINGLE_STEP_P and SOFTWARE_SINGLE_STEP() should be changed to something more appropriate? I can't think of anything off hand. One concern I have is that it may not be known whether a target supports "hardware" single step until it is attempts one. Using the above examples of the sparclite and sparclet, older stubs won't have support for the step command packet. I can't think of a good way to determine ahead of time whether the packet is supported. GDB won't know whether it's OK to use it until it's too late. Perhaps this indicates we should be taking another approach. This is not completely thought out, feel free to shoot holes in it. The step function would be split out of target_resume() into a new vector function target_step(). GDB would unconditionally call target_step(), if it fails with an error code indicating that hardware single step is not available, it would call SOFTWARE_SINGLE_STEP() and then target_resume(). Looking at infrun.c:resume(), it looks like this wouldn't be a trivial exercise. --jtc -- J.T. Conklin RedBack Networks