This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: prev_pc problem on ia64
- From: "J. Johnston" <jjohnstn at redhat dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: Elena Zannoni <ezannoni at redhat dot com>, gdb at sources dot redhat dot com
- Date: Mon, 05 May 2003 15:57:25 -0400
- Subject: Re: prev_pc problem on ia64
- Organization: Red Hat Inc.
- References: <3E973FEB.1090500@redhat.com> <16027.6227.694651.833559@localhost.redhat.com> <3E9C8262.8070401@redhat.com> <3E9C9E1B.4040400@redhat.com> <16028.46200.713351.766037@localhost.redhat.com> <3E9CB85B.5000308@redhat.com> <3E9CCB50.5000908@redhat.com>
Andrew Cagney wrote:
> 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.
target_has_execution doesn't mean that the target is executing. It is
a total misnomer to indicate that the gdb target stratum is capable of
execution. I think what you want is target_has_registers.
Arrrgh! That problem, core file's also has registers ... so right
theory, I've no idea on which thing to use in the test though.
Hmm, ... but at least target_has_registers should only be true when the
target really does have the registers available. I guess try it.
Andrew
There is a problem in my choice of where to set prev_pc. The inferior is not guaranteed
to be stopped when init_execution_control_state() is called so ptrace can fail when
asked to fetch the pc register.
I believe I have found a solution that avoids this problem by refreshing prev_pc in proceed()
just prior to resuming. I will post a patch shortly.
-- Jeff J.