This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] gdb.base/args.exp: Invoke gdb_load for simulator targets


Michael Snyder writes:
 > Andrew Cagney wrote:
 > > 
 > > > On Apr 9, 10:21am, Andrew Cagney wrote:
 > > >
 > > >
 > > >> >    * gdb.base/args.exp: Invoke gdb_load for simulator targets.
 > > >> >    Modify regexps to match extra output after program exit in a
 > > >> >    simulator.
 > > >
 > > >>
 > > >> What's the extra output?  That part may be a bug.
 > > >
 > > >
 > > > When running on a simulator, I see:
 > > >
 > > >     (gdb) target sim
 > > >     Connected to the simulator.
 > > >     (gdb) load gdb.base/args
 > > >     (gdb) run
 > > >     Starting program: .../gdb.base/args 1 3
 > > >     3
 > > >     .../gdb.base/args
 > > >     1
 > > >     3
 > > >
 > > >     Program exited normally.
 > > >     [Switching to process 0]
 > > >     Current language:  auto; currently asm
 > > >     (gdb)
 > > >
 > > > When running with a native gdb, I see:
 > > >
 > > >     (gdb) run
 > > >     Starting program: .../gdb.base/args 1 3
 > > >     3
 > > >     .../gdb.base/args
 > > >     1
 > > >     3
 > > >
 > > >     Program exited normally.
 > > >     (gdb)
 > > >
 > > > The extra output is the bit about switching to process 0 and reporting
 > > > the current language.  I figured it was a feature, but it may well be
 > > > a bug.  (It seems pretty harmless...)
 > > 
 > > I recall that mysteriously appearing at some stage.  I don't think it is
 > > a feature since `Switching to process 0' doesn't make any sense - if the
 > > program exited normally then there are no processes.
 > > 
 > > I suspect that it is related to the SIM trying to simultaneously be an
 > > embedded board (which can't exit) and a normal UNIX process (which does
 > > exit).
 > 
 > I'd be more inclined to attribute it to some recent change
 > in infrun or close associates.  It thinks the inferior_pid
 > has changed.


That line is printed when we stop (normal_stop) and if
target_has_execution.  Maybe when the target exits, it used to pop
the target stack to a layer for which target_has_execution was 0? It
could be that now that doesn't happen anymore.

What's the target once it stops?

elena


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]