Re: prev_pc problem on ia64

["J. Johnston" <jjohnstn@redhat.com>]

Andrew Cagney wrote:
> (I'll ignore the debug info :-)
> 
>>  > Same function compiled for i686:
>>  >  >    Special opcode 76: advance Address by 5 to 0x804839e and Line 
>> by 1 to 31
>>  >    Special opcode 230: advance Address by 16 to 0x80483ae and Line 
>> by 1 to 32
>>  >    Special opcode 146: advance Address by 10 to 0x80483b8 and Line 
>> by 1 to 33
>>  >    Special opcode 160: advance Address by 11 to 0x80483c3 and Line 
>> by 1 to 34
>>  >  > I have a patch whereby I reset prev_pc in 
>> infrun.c:init_execution_control_state():
>>  >  >    if (prev_pc != 0)
>>  >      prev_pc = read_pc ();
>>  >  > prior to setting the ecs->sal.  This works for me in both 
>> scenarios.  The check for
>>  > 0 was needed because I get a failure on the ia64 trying to read the 
>> pc too early when
>>  > the psr register was invalid.
>>  >
>> maybe read_pc should return an error code? Ah wait, it errors out, so
>> you should encapsulate that in a catch_errors().
> 
> 
> The `prev_pc != 0' test is definitly wrong - that will only work when 
> GDB first starts.  Provided the target_has_execution (?), there 
> shouldn't be an error (if there is, GDB's in bad shape :-), so the 
> change should always assign a value to prev_pc and, conditional on 
> target_has_execution, use the value of read_pc().
> 

I tried to use target_has_execution but that did not work.  The error
I get is that the process does not exist.  The read_pc() routine for the ia64 is doing
a read_register_pid() and it appears that the inferior_ptid is not set up
at a time when target_has_execution is set to true.

Does this observation seem reasonable?

> I'm also left wondering if the prev_func_name assignment in:
> 
>> static void
>> stop_stepping (struct execution_control_state *ecs)
>> {
>>   if (target_has_execution)
>>     {
>>       /* Assuming the inferior still exists, set these up for next
>>          time, just like we did above if we didn't break out of the
>>          loop.  */
>>       prev_pc = read_pc ();
>>       prev_func_name = ecs->stop_func_name;
>>     }
>>
>>   /* Let callers know we don't want to wait for the inferior anymore.  */
>>   ecs->wait_some_more = 0;
>> }
> 
> 
> should also be moved to init_execution_control_state, and both of those 
> assignments should be deleted.
> 
> Is it possible to move both of these into the ECS state?
> 
>> please post the patch to gdb-patches. It's hard to judge, like this.
> 
> 
> Yes.
> 
> Andrew
> 
>