>From 1ba3070160d5baab73ba9e500ed58d0ace7121aa Mon Sep 17 00:00:00 2001
From: Steven Seeger
Date: Mon, 26 Mar 2018 20:50:53 -0400
Subject: [PATCH 2/6] leon3: add smp cpu index to asr17
Signed-off-by: Steven Seeger
---
target/sparc/helper.c| 5 +
target/sparc/helper.h| 1 +
tar
>From f512606776e20dc603b8ea3faaeb103667de3178 Mon Sep 17 00:00:00 2001
From: Steven Seeger
Date: Sun, 25 Mar 2018 17:58:21 -0400
Subject: [PATCH 1/6] leon3: change the handling for ASI_LEON_NOCACHE to be
aware of if the MMU is enabled or not
Signed-off-by: Steven Seeger
---
target/sp
All,
I think that the issue I pointed out the list is not a QEMU bug at all but a
GDB bug. GDB's sparc software single step implementation seems to be what is
stuck. It always re-sets the breakpoint at the current instruction in this
case. It calculates the breakpoint offsets by analyzing the i
Oh, let me also add that this assertion fails in gdb:
Thread 1 hit Breakpoint 3, 0x40f102d8 in ?? ()
(gdb) si
./../../src/gdb-8.1/gdb/sparc-tdep.c:1737: internal-error: std::vector sparc_software_single_step(regcache*): Assertion
`nnpc != npc || orig_npc == 0' failed.
I had this assertion commen
On Thursday, February 15, 2018 2:39:34 PM EST Peter Maydell wrote:
> On 15 February 2018 at 19:15, Steven Seeger
> These changes look rather odd -- are you sure they're right?
> This is the code for unconditional taken branch, not annulled, and
> my copy of the sparc architecture
is case.
>From 113357ed067ec64348a51bf40f97c909f85f5d95 Mon Sep 17 00:00:00 2001
From: Steven Seeger
Date: Thu, 15 Feb 2018 13:47:42 -0500
Subject: [PATCH 2/2] handle case of delayed control transfer couple with
leading branch being conditional. need to correctly take the new branch if
conditional is unta
>From ef3183a1648f45c705b55704de3755f84e9bcf80 Mon Sep 17 00:00:00 2001
From: Steven Seeger
Date: Thu, 15 Feb 2018 13:20:04 -0500
Subject: [PATCH 1/2] fix issue where a branch to pc+4 confuses GDB because pc
and npc are set to the same value
Signed-off-by: Steven Seeger
---
target/sp
Consider the following code:
0x100 cmp %g5, 3
0x104 be 0x200
0x108 b 0x300
I believe this is what is described on page 55 of the sparc v8 manual as
unpredictable behavior, where a Bicc precedes an unconditional branch.
QEMU actually crashes unless run in GDB. Single stepping will a
Consider pc==0x100:
0x100 b 0x104
The uncondtional not-annulled branch will go to 0x104, which is the next
instruction anyway. do_branch() will leave dc->pc and dc->npc both set to
0x104. This causes gdb to have a problem when single stepping. It will be
stuck. QEMU will execute past this so
I wanted to update the list on my progress and a follow-up of the "ppc and
icount" thread.
The issue I was seeing is the case where an io memory write triggers a timer
value to be set. In single-thread TCG, timers are run in
handle_icount_deadline() and once that's done, TBs are executed. Since
> I think this is the issue:
>
> I/O threadvCPU thread
> ---
>executes 1,000,000,000-th instruction
>wakes up I/O thread
> find
On Friday, January 12, 2018 12:19:22 PM EST Paolo Bonzini wrote:
>
> Correct. I mentioned it because you also had "-icount sleep=off" in
> your previous message.
Yes I have tried both. With sleep=off, I get the faster interrupt response
(better granularity) but with sleep=on, it is poor. Again,
On Friday, January 12, 2018 11:52:57 AM EST Paolo Bonzini wrote:
> What is the guest doing in the meanwhile?
The guest is running vxWorks with several threads. The CPU does idle at times.
> virtual time increases only when instructions are executed, or when the
> CPUs are idle (in the latter cas
Hi guys. I'm the poster on the qemu-discuss list about some technical icount
questions and was told to come over here to qemu-devel.
My scenario: x86-64 host running qemu/ppc-softmmu with an unmodfied ppc750 cpu
and a custom board target with chipset I implemented.
I am trying to use icount to
14 matches
Mail list logo
