This is the mail archive of the gdb-patches@sourceware.org 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]

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


On 10/30/2012 04:52 PM, ali_anwar wrote:
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.




Ping.. Is it OK to commit?


-Ali


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