* [Qemu-devel] linux-user NPTL problem with signals
@ 2009-09-23 21:51 Gary Thomas
2009-09-24 14:52 ` Gary Thomas
0 siblings, 1 reply; 3+ messages in thread
From: Gary Thomas @ 2009-09-23 21:51 UTC (permalink / raw)
To: qemu-devel
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?
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] linux-user NPTL problem with signals
2009-09-23 21:51 [Qemu-devel] linux-user NPTL problem with signals Gary Thomas
@ 2009-09-24 14:52 ` Gary Thomas
2009-09-27 14:13 ` Jamie Lokier
0 siblings, 1 reply; 3+ messages in thread
From: Gary Thomas @ 2009-09-24 14:52 UTC (permalink / raw)
To: qemu-devel
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
------------------------------------------------------------
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] linux-user NPTL problem with signals
2009-09-24 14:52 ` Gary Thomas
@ 2009-09-27 14:13 ` Jamie Lokier
0 siblings, 0 replies; 3+ messages in thread
From: Jamie Lokier @ 2009-09-27 14:13 UTC (permalink / raw)
To: Gary Thomas; +Cc: qemu-devel
Gary Thomas wrote:
> 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.
Nasty. NPTL is not the only software which depends on the segment
registers keeping their correct values. Wine, DOSemu among others
depend on all the segment registers.
-- Jamie
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-09-27 14:13 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-09-23 21:51 [Qemu-devel] linux-user NPTL problem with signals Gary Thomas
2009-09-24 14:52 ` Gary Thomas
2009-09-27 14:13 ` Jamie Lokier
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).