[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] linux-user NPTL problem with signals
From: |
Gary Thomas |
Subject: |
Re: [Qemu-devel] linux-user NPTL problem with signals |
Date: |
Thu, 24 Sep 2009 08:52:25 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3 |
On 09/23/2009 03:51 PM, Gary Thomas wrote:
I'm running a multi-threaded program (linux-user on i386). I
have a problem with signals; when one arrives, the running
thread abruptly changes :-(
Anyone have any ideas about this?
I've tracked this down to the fact that there should be a
unique value for the GS segment register (at least) per thread.
This doesn't seem to be the case and when a signal is dispatched,
the GS segment register is updated with [probably] the most recent
value created by a new thread, not the running thread.
Hence, I see this:
qemu: got signal 17, pthread: 0x62289840
queue_signal: sig=17, pthread: 0x62289840
qemu: process signal 17
setup_sigcontext.757 (pthread: 0x62289840) - GS: 0x33/0x43e6f110
do_sigreturn, pthread: 0x62289840
restore_sigcontext.973 (pthread: 0x62289840) - GS: 0x33/0x43e6f110
cpu_x86_load_seg_cache.727 - pthread: 0x62289840, GS: 0x33/0x454c3b70
restore_sigcontext.975 (pthread: 0x62289840) - GS: 0x33/0x454c3b70
The GS values printed are the 'selector' and 'base' respectively.
The 'base' value happens to be the Linux pthread_self() [for the
emulated process]. You can see that this is switching threads
but the system has not really switched threads...
Any help?
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------