From: Greg Kurz <groug@kaod.org>
To: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com>
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
pbonzini@redhat.com, doug16k@gmail.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v1 2/2] gdbstub: don't fail on vCont; C04:0; c packets
Date: Wed, 31 May 2017 20:33:11 +0200 [thread overview]
Message-ID: <20170531203311.116e89fc@bahia.lan> (raw)
In-Reply-To: <20170531194046.6d6eed0f@p-imbrenda.boeblingen.de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2046 bytes --]
On Wed, 31 May 2017 19:40:46 +0200
Claudio Imbrenda <imbrenda@linux.vnet.ibm.com> wrote:
> On Wed, 31 May 2017 19:06:29 +0200
> Greg Kurz <groug@kaod.org> wrote:
>
> > On Wed, 31 May 2017 18:51:06 +0200
> > Claudio Imbrenda <imbrenda@linux.vnet.ibm.com> wrote:
> > [...]
> > > > >
> > > > > This is strange. cpu_index() is defined as:
> > > > >
> > > > > static inline int cpu_index(CPUState *cpu)
> > > > > {
> > > > > #if defined(CONFIG_USER_ONLY)
> > > > > return cpu->host_tid;
> > > > > #else
> > > > > return cpu->cpu_index + 1;
> > > > > #endif
> > > > > }
> > > > >
> > > > > therefore it shouldn't return 0 under any circumstance,
> > > > > and
> > > >
> > > > I think it is 0 for first_cpu in user mode.
> > >
> > > in linux-user/syscall.c:
> > >
> > > info->tid = gettid();
> > > cpu->host_tid = info->tid;
> > >
> > > kernel thread-ids are system-wide unique and can't be 0
> > >
> >
> > This is correct but these lines are in clone_func(). This gets called
> > for all threads but the "main" thread which I believe to be
> > associated to first_cpu.
>
> then IMHO that is a bug and it needs to be corrected. the host_tid
> should be, well, the host tid, and not 0, which is never a valid
> tid for Linux.
>
I tend to agree indeed. It isn't a problem for user mode though since it
doesn't use @host_tid. Only gdbstub does.
$ git grep host_tid
include/exec/gdbstub.h: return cpu->host_tid;
include/qom/cpu.h: * @host_tid: Host thread ID.
include/qom/cpu.h: uint32_t host_tid;
linux-user/syscall.c: cpu->host_tid = info->tid;
> the current behaviour is simply the easiest for the "any CPU" case.
> Picking the last CPU or a random one would still be correct, and in
> that case there would be no way to explicitly address the first CPU.
>
I'm not familiar enough with gdbstub to know if this is a real problem.
But I guess it is possible to add a "first_cpu->host_tid = gettid();" line
somewhere in linux-user/main.c.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2017-05-31 18:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-31 15:09 [Qemu-devel] [PATCH v1 0/2] some gdbstub fixes for debug and vcont Alex Bennée
2017-05-31 15:09 ` [Qemu-devel] [PATCH v1 1/2] gdbstub: modernise DEBUG_GDB Alex Bennée
2017-05-31 15:22 ` Philippe Mathieu-Daudé
2017-05-31 15:50 ` Greg Kurz
2017-05-31 15:09 ` [Qemu-devel] [PATCH v1 2/2] gdbstub: don't fail on vCont; C04:0; c packets Alex Bennée
2017-05-31 16:17 ` Greg Kurz
2017-05-31 16:27 ` Alex Bennée
2017-05-31 16:17 ` Claudio Imbrenda
2017-05-31 16:26 ` Alex Bennée
2017-05-31 16:33 ` Greg Kurz
2017-05-31 16:51 ` Claudio Imbrenda
2017-05-31 17:06 ` Greg Kurz
2017-05-31 17:40 ` Claudio Imbrenda
2017-05-31 18:16 ` Alex Bennée
2017-05-31 18:33 ` Greg Kurz [this message]
2017-05-31 17:23 ` Alex Bennée
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=20170531203311.116e89fc@bahia.lan \
--to=groug@kaod.org \
--cc=alex.bennee@linaro.org \
--cc=doug16k@gmail.com \
--cc=imbrenda@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.