This is the mail archive of the gdb-patches@sourceware.org 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: Can we get rid of go32_stop? (and its normal_stop call?)


> From: Pedro Alves <pedro@codesourcery.com>
> Date: Fri, 1 May 2009 17:24:36 +0100
> 
> IMO, it would be nice to paste your description below at the top of
> go32-nat.c.

Okay, I will do it some time soon.

Btw, this single-process mode is also the reason why we need to play
games with redir_to_child and redir_to_debugger: the file handles are
also shared, so redirection on the "run" command line needs special
handling (and there's no shell involved in interpreting it).

> > So far so good.  But the plot thickens if abnormal events happen, such
> > as an exception inside the debuggee or just a Ctrl-C pressed by the
> > user at a wrong time.  We might get back to GDB before we had a chance
> > to clean up after the debuggee.  
> 
> I see.  To be clear, in this case, is the debuggee considered
> dead and gone?  No further debugging possible?

That's the best we can do, yes.  The debuggee is trashed.

> But, notice one thing --- the go32_ops target
> will still be pushed on the stack, and so the current target still is
> considered to have execution (target_has_execution is true, and
> inferior_ptid will still point at  SOME_PID).  So, when the user does "run",
> GDB will ask if the user wants to kill the current program, and
> will refuse to go ahead if the user says "no".  If the user says
> "yes", then, target_kill is called to kill the current program
> (which ends up in go32_kill_inferior), all before reaching
> go32_create_inferior.
> 
>  This is run_command->kill_if_already_running->target_kill.

Then we probably can remove that conditional call to
go32_kill_inferior.  This is a very old code, perhaps at some past
time it was necessary, I don't know.  Given your description, it seems
we don't need it anymore.

> Currently, "kill" doesn't call `cleanup_client', after
> my changes, it will --- I'm assuming that to be a good thing.

Yes.

> :-)  I think that with my proposed change, we get the same ammount
> of paranoia (even more), but, this needs to be at least minimally
> tested, of course.

I patched my snapshot with your changes, let me run with it for some
time and see if anything goes wrong.  You can commit the changes in
the meantime.

Thanks.

Out of curiosity: why was normal_stop sentenced to death?

> BTW, have you ever had any success running djgpp from inside an
> emulator on linux, say, 'dosemu'?

I never had time to set that up.  Maybe DJ did.


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