Re: bsd-kvm target, always a thread

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Sat, 9 Aug 2008 15:29:08 +0100
> 
> On Saturday 09 August 2008 13:11:16, Mark Kettenis wrote:
> > > From: Pedro Alves <pedro@codesourcery.com>
> > > Date: Sat, 9 Aug 2008 12:27:34 +0100
> > >
> > > On Saturday 09 August 2008 09:32:57, Mark Kettenis wrote:
> > > > > From: Pedro Alves <pedro@codesourcery.com>
> > > >
> > > > Hmm, it is unfortunate that a process ID of 0 is "verboten", since
> > > > that's what you are really looking at with "target kvm".  And it
> > > > should be possible for me to actually make all the running processes
> > > > visible as kernel "threads".
> > > >
> > > >
> > > > I guess your diff is right, although I'd prefer a less arbitrary ptid
> > > > to be used.  Would something like ptid_build(0, 1, 0) work?
> > >
> > > I'd prefer to get away without pid == 0.  I'm going to
> > > introduce later a "struct inferior" which holds an "int pid", and
> > > we will match a ptid to a struct inferior by its ptid.pid.
> > > I'd rather avoid having an inferior with pid == 0.
> > >
> > > Does something like this work for you?
> >
> > Something like that'd work fine for the OpenBSD kernel.
> 
> > Sure, I'd just think you should use something that's a bit less
> > arbitrary than 42000 (which could be confused with a real process ID)
> > here.  
> 
> Eh, 42 carries some history.  :-)  It was used in several targets already,
> even before I started changing then to use ptid(pid,0,tid), and always
> registering a thread.  monitor used 42000, remote used 42000, remote-sim
> used 42, go32-nat.c uses 42.  I just thought that carrying it around
> would make it easier to spot what it is.

I can see where that 42 is coming from.  So 42000 can defenitely not
be the answer! ;).

Seriously though, the fact the it was changed for 42 to 42000 in some
places is a hint that there is a problem here.  There must have been a
collision between 42 and a real process ID somehwre.  And I guess it
was changed to 42000 since many Unix systems process IDs are 16-bit.
But there may be modern systems around that use larger values.

> Let's not use -1, as that conflicts a bit with the special
> ptid(-1,0,0) (aka, minus_one_ptid).

Not if you set the lwpid or tid to something non-zero.

> I actually have a patchlet in my series to bring back the 42000:
> 
>  remote.c:
>    /* Take advantage of the fact that the LWP field is not used, to tag
>       special ptids with it set to != 0.  */
>  -  magic_null_ptid = ptid_build (0, 1, -1);
>  -  not_sent_ptid = ptid_build (0, 1, -2);
>  -  any_thread_ptid = ptid_build (0, 1, 0);
>  +  magic_null_ptid = ptid_build (42000, 1, -1);
>  +  not_sent_ptid = ptid_build (42000, 1, -2);
>  +  any_thread_ptid = ptid_build (42000, 1, 0);
> 
> I guess we're numerically converging :-)

Well, that diff would be simply wrong!  What if you're debugging
process ID 42000 remotely?  

> How about the attached?
> 
> With your fix for the %eip in, I now get,
> 
>  (gdb) tar kvm
>  #0  0xd034ee05 in ?? ()
>  (gdb) info threads
>  * 1 <kvm>  0xd034ee05 in ?? ()
> 
> OK?

I guess this will do for now.

> 2008-08-09  Pedro Alves  <pedro@codesourcery.com>
> 
> 	* bsd-kvm.c: Include "gdbthread.h".
> 	(bsd_kvm_ptid): New.
> 	(bsd_kvm_open): Add a main thread.
> 	(bsd_kvm_close): Delete it.
> 	(bsd_kvm_thread_alive): New.
> 	(bsd_kvm_pid_to_str): New.
> 	(bsd_kvm_add_target): Register bsd_kvm_thread_alive and
> 	bsd_kvm_pid_to_str.
> 	(bsd_kvm_add_target): Initialize bsd_kvm_ptid.