Re: [rfc] Do not call read_pc in startup_inferior

[Pedro Alves <pedro at codesourcery dot com>]

On Wednesday 29 April 2009 13:32:56, Ulrich Weigand wrote:
> Daniel Jacobowitz wrote:
> > On Tue, Apr 28, 2009 at 06:37:12PM +0200, Ulrich Weigand wrote:
> > > Hello,
> > > 
> > > a while ago, I committed a patch to avoid calling wait_for_inferior
> > > in startup_inferior, so as to avoid accessing inferior register state
> > > at a time where the target's actual register layout has not yet been
> > > determined (via target_find_description).
> > > 
> > > However, startup_inferior still contains a read_pc call to retrieve
> > > the initial value of stop_pc -- this of course runs into the same
> > > problem.
> > > 
> > > The patch below removes the read_pc call from startup_inferior, and
> > > instead determines the initial stop_pc value in post_create_inferior,
> > > after the register layout has been finalized.
> > 
> > You're moving the call from a native "run" only routine, to an
> > all-targets routine.  That made me curious so I went looking... what
> > relies on this setting?  Anything?
> 
> It doesn't seem a lot relies on it; the solib_create_inferior_hook
> might, but this is the case only for solib-sunos.c (which I guess
> could be changed to use regcache_read_pc).
> 
> The only other potentially user-visible change seems to be that
> "info program" will report "Program stopped at ..." giving the
> proper entry point address.
> In any case, most create_inferior implementations either call
> startup_inferior, or otherwise set stop_pc e.g. by calling into
> wait_for_inferior (in the latter case it shouldn't hurt to set
> it again).
> 
> There are some targets that currently do not appear to set stop_pc:
> the remote-extended mode, NTO, and some monitor targets.  These
> would see a difference in "info program" output due to my patch
> (but the new behaviour should be preferable, I guess) ...
> 

Actually, currently it is hard to stop at the entry point
in most targets.  `proceed' will step over a breakpoint set right
at the entry point exactly due to this stop_pc == current pc, even
if it was never hit.  This leads to people using the "set breakpoint
at `entry point' + 1, instead of `entry point'" trick.

Maybe we should make run_command_1
call `proceed (current_pc, TARGET_SIGNAL_0, 0)' instead of
`proceed (-1, TAR...)'.  This would (partially) fix the bpkt at
entry issue, while also making sure that `proceed' isn't faced with a
completely random random stop_pc if we pass it -1.

(I believe there are other problems that make GDB ignore
breakpoints set at the entry point, e.g., if it happens to
be the same place we have a BPSTAT_WHAT_CHECK_SHLIBS breakpoint.)

-- 
Pedro Alves