From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25202 invoked by alias); 10 Aug 2008 15:56:49 -0000 Received: (qmail 25185 invoked by uid 22791); 10 Aug 2008 15:56:47 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 10 Aug 2008 15:56:12 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id m7AFsqma007612; Sun, 10 Aug 2008 17:54:52 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id m7AFsqwE027830; Sun, 10 Aug 2008 17:54:52 +0200 (CEST) Date: Sun, 10 Aug 2008 15:56:00 -0000 Message-Id: <200808101554.m7AFsqwE027830@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: pedro@codesourcery.com CC: gdb-patches@sourceware.org In-reply-to: <200808091529.08896.pedro@codesourcery.com> (message from Pedro Alves on Sat, 9 Aug 2008 15:29:08 +0100) Subject: Re: bsd-kvm target, always a thread References: <200808080420.05897.pedro@codesourcery.com> <200808091227.35031.pedro@codesourcery.com> <200808091211.m79CBGfO008457@brahms.sibelius.xs4all.nl> <200808091529.08896.pedro@codesourcery.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-08/txt/msg00276.txt.bz2 > From: Pedro Alves > Date: Sat, 9 Aug 2008 15:29:08 +0100 > > On Saturday 09 August 2008 13:11:16, Mark Kettenis wrote: > > > From: Pedro Alves > > > Date: Sat, 9 Aug 2008 12:27:34 +0100 > > > > > > On Saturday 09 August 2008 09:32:57, Mark Kettenis wrote: > > > > > From: Pedro Alves > > > > > > > > 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 0xd034ee05 in ?? () > > OK? I guess this will do for now. > 2008-08-09 Pedro Alves > > * 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.