> 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 they are some bugs in the implementation). The fact that > they are or not used by computations is another point. The fact is the > registers values are correct.
AFAICS the high bits are never used by anything. 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. > And the fact is that printing a uint64_t on any 64 bits host (x86_64 or > any other) using PRIx64 is exactly what is to be done, according to ISO > C. Then, pretending that it would crash on any host is completelly > pointless. We weren't printing a 64-bit value. We were passing a 32-bit target_ulong with a PRIx64 format. Some concrete examples: translate.c:6052: cpu_fprintf(f, "MSR " REGX FILL " HID0 " REGX FILL " HF " REGX FILL env->msr, env->hflags, env->spr[SPR_HID0], All these values are 32-bit tagret_ulong. Using a 64-bit format specifierfor ppc32 targets is just nonsense. And at line 6069 we even have an explicit cast to a 32-bit type: cpu_fprintf(f, " " REGX, (target_ulong)env->gpr[i]); > > I see the SPE stuff that uses T0_64 et al, however this still uses > > stores the value in the low 32 bits of the {gpr,gprth} pair. > > SPE dump is the case that does not work properly. Your patch does not solve > anything here, just breaks the main stream case. I agree that SPE register dumping does not work, however I also assert that it was never even close to working, and if REGX is supposed to be the solution then most of the uses of REGX are incorrect. Please give a concrete example of something that worked before and does not now. Paul