Bugs item #1837091, was opened at 2007-11-23 15:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=1837091group_id=180599
Please note that this message will contain a full copy of
Then I took a closer look to the code, to ensure I was not wrong.
The PowerPC 32 on 64 bits hosts is implemented the same way that the
specification says a PowerPC in 32 bits mode should be. Then higher bits
are not garbage. They are what the PowerPC specification say they should
be (apart if
Paul Brook wrote:
I think what you mean is that they work the way that ppc64 is defined, to
remain compatible with ppc32. IMHO this is entirely irrelevant as we're
emulating a ppc32. You could replace the high bits with garbage and
nothing would ever be able to tell the difference.
On Sat, 2007-11-24 at 00:52 +, Paul Brook wrote:
By your own admission, we can get away with not calculating the
high 32 bit of the register. If follows that the high bits are completely
meaningless.
Not completelly. There are even some way to do 64 bits computations when
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/24 03:09:07
Modified files:
hw : arm-misc.h arm_gic.c armv7m_nvic.c stellaris.c
Log message:
ARMv7-M SysTick fix.
CVSWeb URLs:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/24 03:13:04
Modified files:
. : Makefile.target
hw : arm-misc.h armv7m_nvic.c stellaris.c
Added files:
hw : stellaris_enet.c
Log message:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer j_mayer 07/11/24 02:03:56
Modified files:
target-ppc : cpu.h exec.h helper.c op_helper.c translate.c
Log message:
Fix incorrect debug prints (reported by Paul Brook).
Remove obsolete /
J. Mayer wrote:
[snip]
Showing more than 32 bits of register
is completely bogus.
No. It's showing the full CPU state, which can be more than what the
application (or the OS, when running virtualized on a real CPU) could
see. The OS cannot see the whole CPU state, but Qemu must
Hi,
There is a chance that when using unix or dynticks clock, the
signal arrives when no cpu is executing. The probability is high when
using dynticks and a timer is scheduled to expire very soon so that a
signal is delivered very soon after a previous signal. When that
happens cpu_single_env is
I think what you mean is that they work the way that ppc64 is defined, to
remain compatible with ppc32. IMHO this is entirely irrelevant as we're
emulating a ppc32. You could replace the high bits with garbage and
nothing would ever be able to tell the difference.
PowerPC is a 64 bits
The old code before the patch is obviously broken. It's mixing 64-bit
(ppc_gpr_t) and 32-bit (target_ulong) values.
It seems you do not understand that what was done was correct. It's not
mixing two different types. GPR are of ppc_gpr_t type and should be
displayed this way.
It's not
On Fri, 2007-11-23 at 18:22 +, Paul Brook wrote:
Furthermore this patch was made in a brainless way, it will be reverted
asap.
If you think there is a bug in someone else code, submit it a patch, if
it's cleaver and addresses a real bug (which is not the case here) it
will be
Furthermore this patch was made in a brainless way, it will be reverted
asap.
If you think there is a bug in someone else code, submit it a patch, if
it's cleaver and addresses a real bug (which is not the case here) it
will be accepted and merged.
The old code before the patch is obviously
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/23 17:33:13
Modified files:
hw : ppc_oldworld.c
target-ppc : cpu.h helper.c op_helper.c
Log message:
Fix ppc32 register dumps on 64-bit hosts.
CVSWeb URLs:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/11/23 16:54:00
Modified files:
. : exec.c
Log message:
Fix va_list reuse in cpu_abort.
CVSWeb URLs:
On Fri, Nov 23, 2007 at 02:48:34PM +0100, andrzej zaborowski wrote:
If that's really the case, I'm curious why it's distributed in its
binary form rather than being built at runtime.
build-time?
Yes, my mistake :)
Perhaps because the (cross-)compiler used to build the BIOS is not
present
Soren Hansen wrote:
On Thu, Nov 22, 2007 at 01:47:22PM -0500, Markus Schulz wrote:
Thank you for your response; I think the file can be found here:
http://cvs.savannah.nongnu.org/viewvc/qemu/pc-bios/?root=qemu
As far as I understand Qemu uses the BIOS from the Bochs project and
the diff
Hi,
I would like to modify Qemu code so that I can log guest memory
reads on certain area of memory. Guest is PPC PREP and area I like to
monitor is Residual data area. How should I do this? Where to start?
Tero
On Thu, Nov 22, 2007 at 01:47:22PM -0500, Markus Schulz wrote:
Thank you for your response; I think the file can be found here:
http://cvs.savannah.nongnu.org/viewvc/qemu/pc-bios/?root=qemu
As far as I understand Qemu uses the BIOS from the Bochs project and
the diff is applied for Qemu and
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Jocelyn Mayer j_mayer 07/11/24 02:56:36
Modified files:
hw : ppc.c ppc405_uc.c ppc4xx_devs.c ppc_chrp.c
ppc_oldworld.c ppc_prep.c
Log message:
More PowerPC debug print fixes
On Fri, 2007-11-23 at 17:33 +, Paul Brook wrote:
CVSROOT: /sources/qemu
Module name: qemu
Changes by: Paul Brook pbrook 07/11/23 17:33:13
Modified files:
hw : ppc_oldworld.c
target-ppc : cpu.h helper.c op_helper.c
Log message:
Fix
andrzej zaborowski wrote:
On 21/11/2007, dara burke [EMAIL PROTECTED] wrote:
Hi Guys,
I've been looking around for a solution to this problem that I've been
having with qemu on ubuntu Gutsy. It seemed to work fine on Feisty, but I
haven't been able to find anyone else with a similar
On Fri, 2007-11-23 at 19:42 +0100, Jocelyn Mayer wrote:
On Fri, 2007-11-23 at 18:22 +, Paul Brook wrote:
Furthermore this patch was made in a brainless way, it will be reverted
asap.
If you think there is a bug in someone else code, submit it a patch, if
it's cleaver and
On Fri, 2007-11-23 at 19:10 +, Paul Brook wrote:
The old code before the patch is obviously broken. It's mixing 64-bit
(ppc_gpr_t) and 32-bit (target_ulong) values.
It seems you do not understand that what was done was correct. It's not
mixing two different types. GPR are of
On Fri, 2007-11-23 at 21:36 +, Paul Brook wrote:
Then I took a closer look to the code, to ensure I was not wrong.
The PowerPC 32 on 64 bits hosts is implemented the same way that the
specification says a PowerPC in 32 bits mode should be. Then higher bits
are not garbage. They are
On Fri, 2007-11-23 at 22:23 +, Paul Brook wrote:
I think what you mean is that they work the way that ppc64 is defined, to
remain compatible with ppc32. IMHO this is entirely irrelevant as we're
emulating a ppc32. You could replace the high bits with garbage and
nothing would
There is a chance that when using unix or dynticks clock, the
signal arrives when no cpu is executing.
I've seen similar stalls, but not managed to track down the source. Your
analysis seems correct.
+ /* cause an interrupt in the first cpu that tries to start running */
+ if (!env)
Well, I admit I've invented the term ppc32, but there are dozens of
32-bit PowerPC chips. I'd be amazed if they do 64-bit computations or have
64-bit GPRs.
Indeed not. Valgrind implements the 32-bit PPC user-space instruction set
quite adequately using 32-bit computations throughout. No
28 matches
Mail list logo
