Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: gdb-patches@sourceware.org
Subject: Re: bsd-kvm target, always a thread
Date: Sat, 09 Aug 2008 11:28:00 -0000	[thread overview]
Message-ID: <200808091227.35031.pedro@codesourcery.com> (raw)
In-Reply-To: <200808090832.m798Wvbc001860@brahms.sibelius.xs4all.nl>

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?

    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


  reply	other threads:[~2008-08-09 11:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-08  3:20 Pedro Alves
2008-08-09  8:17 ` Mark Kettenis
2008-08-09  8:34 ` Mark Kettenis
2008-08-09 11:28   ` Pedro Alves [this message]
2008-08-09 12:13     ` Mark Kettenis
2008-08-09 14:31       ` Pedro Alves
2008-08-10 15:56         ` Mark Kettenis
2008-08-10 17:34           ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200808091227.35031.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=mark.kettenis@xs4all.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox