From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29796 invoked by alias); 9 Aug 2008 11:28:10 -0000 Received: (qmail 29788 invoked by uid 22791); 9 Aug 2008 11:28:10 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 09 Aug 2008 11:27:35 +0000 Received: (qmail 7894 invoked from network); 9 Aug 2008 11:27:33 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 9 Aug 2008 11:27:33 -0000 From: Pedro Alves To: Mark Kettenis Subject: Re: bsd-kvm target, always a thread Date: Sat, 09 Aug 2008 11:28:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb-patches@sourceware.org References: <200808080420.05897.pedro@codesourcery.com> <200808090832.m798Wvbc001860@brahms.sibelius.xs4all.nl> In-Reply-To: <200808090832.m798Wvbc001860@brahms.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808091227.35031.pedro@codesourcery.com> X-IsSubscribed: yes 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/msg00231.txt.bz2 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? ptid(42000, 0, 0) -> for use when we pass around a ptid representing the whole inferior. ptid(42000, 1, 0) -> in kernel ptid(42000, 1, 1) -> process 1. ptid(42000, 1, 2) -> process 2 ptid(42000, 1, 3) -> process 3 ... Or, does it make sense to have one or more threads for the kernel, distinct from user visible processes? ptid(42000, 0, 0) -> for use when we pass around a ptid representing the whole inferior. ptid(42000, 1, 1) -> kernel thread/context 1 ptid(42000, 1, 2) -> kernel thread/context 2 ... ptid(42000, 0, 1) -> user process 1. ptid(42000, 0, 2) -> user process 2 ptid(42000, 0, 3) -> user process 3 ... These are internal ids, of course. We only show them what we want in target_pid_to_str and target_extra_thread_info. The user doesn't need to know anything about these ids. -- Pedro Alves