Re: [rfc] Do not call read_pc in startup_inferior

[Pedro Alves <pedro at codesourcery dot com>]

On Monday 04 May 2009 18:38:59, Ulrich Weigand wrote:
> Makes sense. ?This means we'd have to remember the "thread we last
> stopped at" so we can show its stop_pc. ?I don't think we actually
> have this information right now?

We have `get_last_target_status', which infcmd.c:program_info
already uses.

> Indeed.  That's another odd corner that I've never quite understood:
> at the point where we look at breakpoints, the "bpstat" structure is
> already able to represent that multiple causes of actions have occurred
> at the same time.  But this detailed status is then reduced via bpstat_what
> to a single action code ...   Maybe handle_inferior_event should
> really make full use of all the information present in the bpstat.

Yeah...  I think that the basic idea was that most of the stop
actions in the bpstat structure are mutually exclusive.  E.g.,
set-longjmp-resume, step-resume, longjmp-resume, single-stepping,
user breakpoints.  If you're handling one of these, all the other
actions that could be associated with one of the other
simultaneous breakpoints should be cancelled, so in a sense, the 
ordering and reducing make some sense.  This breaks if the actions
aren't really mutually exclusive, like in the shlib event case.
Probably, something like eliminating BPSTAT_WHAT_CHECK_SHLIBS and
adding a check_shlibs boolean field to `struct bpstat_what'
isn't too far from fixing this case.

-- 
Pedro Alves