Hi..
On Mon, Mar 10, 2008 at 3:19 AM, Christian MICHON
<[EMAIL PROTECTED]> wrote:
> On 3/9/08, Steve Fosdick <[EMAIL PROTECTED]> wrote:
> > I have found a single config change that causes the problem. With:
> >
> > # CONFIG_HIGH_RES_TIMERS is not set
> >
> > kqemu works correctly, whereas wit
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Aurelien Jarno 08/03/10 00:12:14
Modified files:
hw : gt64xxx.c
Log message:
GT64XXX: fix endianness issues:
- Byte swapping for internal GT64XXX registers is controlled by the
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Aurelien Jarno 08/03/10 00:09:28
Modified files:
target-ppc : op_helper.c
Log message:
mtfsf: fix FPSCR_VX and FPSCR_FEX computation
The patch below fixes the computation of FPSCR_
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Aurelien Jarno 08/03/10 00:05:35
Modified files:
. : block.c
Log message:
Honor TMPDIR environment variable
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/block.c?cvsroot=qemu&r1=1.53&
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Aurelien Jarno 08/03/10 00:02:11
Modified files:
hw : e1000.c
Log message:
Change the e1000 mmio addr space according to spec.
According to the Intel 82540EM manual, the mm
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Aurelien Jarno 08/03/09 23:43:49
Modified files:
. : vl.c
Log message:
Be consistent in -clock parameter. Display also the list of available
sources if no valid clock name has been spe
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl 08/03/09 20:46:51
Modified files:
target-sparc : op.c translate.c
Log message:
Convert andn, orn and xnor to TCG
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op.c?cvsroot=qem
On 3/9/08, Steve Fosdick <[EMAIL PROTECTED]> wrote:
> I have found a single config change that causes the problem. With:
>
> # CONFIG_HIGH_RES_TIMERS is not set
>
> kqemu works correctly, whereas with:
>
> CONFIG_HIGH_RES_TIMERS=y
>
> the problem appears. Any idea why that causes a problem? Is it
M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Jamie Lokier <[EMAIL PROTECTED]> writes:
> : Btw, unfortunately pthread_self() is not safe to call from signal
> : handlers.
>
> And also often times meaningless, as signal handlers can run in
> arbitrary threads...
That's usua
On Sun, Mar 09, 2008 at 11:26:43AM +0200, Gilad Ben-Yossef wrote:
> Glauber Costa wrote:
> > This patch introduces a "thread_id" variable to CPUState.
> > It's duty will be to hold the process, or more generally, thread
> > id of the current executing cpu
> >
> > env->nb_watchpoints = 0;
> >
In message: <[EMAIL PROTECTED]>
Gilad Ben-Yossef <[EMAIL PROTECTED]> writes:
: > What you're supposed to do with pthreads in general is use pthread_self().
:
: Unfortunately, AFAIK the opaque handle that pthread_self() returns is
: not quite meaningless outside of the process whereas
In message: <[EMAIL PROTECTED]>
Jamie Lokier <[EMAIL PROTECTED]> writes:
: Btw, unfortunately pthread_self() is not safe to call from signal
: handlers.
And also often times meaningless, as signal handlers can run in
arbitrary threads...
Warner
Jamie Lokier wrote:
Gilad Ben-Yossef wrote:
Glauber Costa wrote:
This patch introduces a "thread_id" variable to CPUState.
It's duty will be to hold the process, or more generally, thread
id of the current executing cpu
env->nb_watchpoints = 0;
+#ifdef __WIN32
+env->thread_id = GetCurr
Gilad Ben-Yossef wrote:
> Glauber Costa wrote:
> >This patch introduces a "thread_id" variable to CPUState.
> >It's duty will be to hold the process, or more generally, thread
> >id of the current executing cpu
> >
> > env->nb_watchpoints = 0;
> >+#ifdef __WIN32
> >+env->thread_id = GetCurr
Glauber Costa wrote:
This patch introduces a "thread_id" variable to CPUState.
It's duty will be to hold the process, or more generally, thread
id of the current executing cpu
env->nb_watchpoints = 0;
+#ifdef __WIN32
+env->thread_id = GetCurrentProcessId();
+#else
+env->thread_id =
15 matches
Mail list logo
