Patch to propagate GDB's knowledge of the executing state to frontend

[ali_anwar]

On 10/30/2012 11:20 AM, Yao Qi wrote:
> On 10/25/2012 07:09 PM, ali_anwar wrote:
>> Hi,
>>
>> Attached patch is to let GDB propagate the target state under following
>> two scenarios:
>>
>> 1. Attached patch will enable GDB to inform about the state of the
>> target when it was not able to fetch the non-general registers, when
>> target is already stopped.
>>
>> The reason behind this behavior was an error message which was caused
>> when the GDB was not able to fetch the value of a certain register. The
>> GDB should have told the front end about the current state of the
>> target. The attached patch makes sure that it happens. This patch should
>> be a safety measure in case some debugging stub behaves badly.
>>
>> 2. Attached patch will enable GDB to inform about the state of the
>> target when it was not able to fetch the backtrace once the step has
>> already occurred and target is in stopped state.
>>
>
> It is better to describe what will happen or what is wrong if this patch
> is not applied.
>

Thanks Yao for the review. Let me restate the actual problem:

Under certain scenarios, GDB is unable to specify the correct target 
state once the step/finish instruction is executed.

1. If you perform a step out (finish) and there is an error when GDB 
tries to fetch the register values.

2. If you perform a ste and there is an error when GDB tries to fetch 
the backtrace.

In both the cases the only output is an error message and nothing is 
printed as far as current target state is concerned.e.g.


(gdb)
-exec-finish
^running
*running,thread-id="all"
(gdb)
^error,msg="Could not fetch register \"\"; remote failure reply 'E22'"
(gdb)


In other words from MI's perspective, the step hasn't completed yet – 
the state is still "running".

The only concern is GDB not printing the state of the target. It does 
not matter why the error occurred.

>> + executing state to frontend when not able to fetch registers.
>> + (wait_for_inferior): Chnage to propagate GDB's knowledge of
> ^^^^^^ typo
>
>
>> + the executing state if not able to fetch backtrace once the
>> + step has already occured.
> ^^^^^^^ typo.
>

I will fix the both typos.

> In each changelog entry, we'll put 'what do we change' instead of 'why
> do we change in this way'. So this entry can be simplified.
>

I will look into it as well.

>> + handle_inferior_event (ecs);
>> + return (0);
>
> parentheses are not needed.
>
>> +}
>> +
>> + return (0);
>
> Likewise.
>

I will remove the parentheses.


Thanks,
-Ali