Re: [djgpp/commit] Fix go32_pid_to_str and go32_thread_alive

[Eli Zaretskii <eliz at gnu dot org>]

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Fri, 1 May 2009 11:18:51 +0100
> 
> On Friday 01 May 2009 09:17:15, Eli Zaretskii wrote:
> 
> > 2009-05-01  Eli Zaretskii  <eliz@gnu.org>
> > 
> > 	* go32-nat.c (go32_pid_to_str): Call normal_pid_to_str instead of
> > 	printing a bogus "Thread <main>".
> 
> I thought that the inferior's PID on DJGPP is always the
> fake SOMEPID (42)

True.

> an internal implementation detail, that we'd
> never want to show to the user, but, normal_pid_to_str will
> print "process 42" here.  Isn't that bogus as well?

It is, to some degree.  But IMO talking about threads in an
environment that doesn't support threads is a greater lie, so
to say ;-)  I wanted the output to be more like when one debugs
a single-threaded program on Unix, because when I first saw
that "Thread <main>" displayed by "set debug infrun 1", I
thought there's some bug somewhere whereby GDB thinks it's
debugging a multithreaded program. 

DJGPP users are already used to see 42 popping here and there; e.g.,
that's what getuid and getgid return for the only user and group they
support.

I briefly considered a possibility to add a function to more
faithfully fake the PID of the inferior (DJGPP's version of getpid
simply returns the current BIOS clock tick counter, so I could fetch
that from GDB), but eventually I decided it wasn't worth the hassle.

> > 	(go32_thread_alive): Don't return 1 for null_ptid.
> 
> Interesting.  This may be masking some other problem.  How
> did you get here with inferior_ptid == null_ptid?

I didn't.  It just seemed unclean to me to return 1 for null_ptid,
when just a little ways above, in go32_stop, we assign it when we
delete the single alive thread.

> AFAICS, when the inferior exits or is killed, the go32_ops target is
> unpushed.

I have no doubt that you are right, but at some future point this
method could potentially be called in some other context.

If you think my change may mask other problems, now or in the future,
I'm okay with adding some appropriate gdb_assert here.

Thanks for the feedback.