qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]