Re: target_find_description question

[Daniel Jacobowitz <drow@false.org>]

On Thu, Sep 04, 2008 at 09:16:33PM +0200, Ulrich Weigand wrote:
> Daniel Jacobowitz wrote:
> 
> > I suppose the easiest thing to do would be to call
> > target_find_description right before handle_inferior_event, and rely
> > on target_desc_fetched to prevent duplicate work.
> 
> Unfortunately, it turns out this doesn't work.  Or rather, it works
> too well: target_find_description is called after the first stop,
> and determines target properties -- while the inferior process is
> still executing the shell we're using to start up the real inferior!

Whoops.  I didn't think of that.

> So it'll detect e.g. a 32-bit inferior because the shell is 32-bit,
> even though the real inferior is a 64-bit application ...
> 
> I guess we do need to defer target_find_description until after the
> real inferior is started.  However, we then have the problem of how
> to handle those register/memory accessed in the mean time.

Shouldn't accessing the shell's registers always be a bug, admitted
one that we already have?  We don't have symbols for it, we don't
support breakpoints in it, et cetera.  We used to have some global
information about the number of expected traps, but now it's local.

> Maybe we can change handle_inferior_event to not do any PC processing
> if stop_soon is set?

I don't think that will work, e.g. solib-irix.c and various other
solib modules run expecting to hit a breakpoint.

-- 
Daniel Jacobowitz
CodeSourcery