[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] linux-user: fix multi-threaded /proc/self/maps
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [PATCH] linux-user: fix multi-threaded /proc/self/maps |
Date: |
Fri, 1 Jun 2012 03:17:31 +0100 |
On 1 June 2012 02:45, Alexander Graf <address@hidden> wrote:
> On 01.06.2012, at 03:39, Peter Maydell <address@hidden> wrote:
>> On 1 June 2012 02:16, Alexander Graf <address@hidden> wrote:
>>> On 01.06.2012, at 02:44, Peter Maydell wrote:
>>>> So in the multithreaded case do all the thread stacks live
>>>> in this one mapping, or do the non-primary thread stacks
>>>> live in a standard mmap'd mapping?
>>>
>>> I thought /proc/self/maps always shows the initial stack map as [stack]?
>>
>> I dunno, I asked because I'm too lazy to check myself :-)
>
> Same here. Mind to check? Your time zone fits this better atm ;)
So none of the processes on my system have more than one [stack]
mapping, even the multithreaded ones. OTOH the kernel sources:
http://lxr.free-electrons.com/source/fs/proc/task_mmu.c#L262
indicate that it is possible for them to print [stack:TID] for
a thread stack in some cases...
However, I think your change is right, because the secondary
threads ought to see the main process /proc/self/maps and
that should show the main stack.
Q: I think the reason for the
#if defined(TARGET_ARM) || defined(TARGET_M68K) || defined(TARGET_UNICORE32)
is because linux-user/main.c only sets up ts->stack_base
on those targets. If we're not using ts->stack_base
any more can we drop the #if here?
(more generally I wonder if we can drop ts->stack_base completely
in favour of ts->info->start_stack...)
-- PMM