On 16 January 2014 17:51, Alexander Graf <ag...@suse.de> wrote: >> Am 16.01.2014 um 18:41 schrieb Peter Maydell <peter.mayd...@linaro.org>: >> Also see my remarks on the previous patch series suggesting >> that we should look at this in a more holistic way than >> just randomly fixing small bits of things. A good place >> to start would be "what should the semantics of stl_p() >> be for a QEMU where the CPU is currently operating with >> a reversed endianness to the TARGET_WORDS_BIGENDIAN >> setting?". > > That'd open a giant can of worms that I'd rather not open.
If you don't want to open the can of worms then your correct path is to use QEMU's existing mechanisms for BE/LE support -- build a separate executable for the other endianness, which will then have TARGET_WORDS_BIGENDIAN set appropriately, and the gdb register read functions will work correctly. Attempting to handle either-endian guests in the same executable is exactly opening the can of worms, and if we're doing it we should do it with some kind of plan of attack for killing the worms. > RTAS for example is still BE regardless of guest endianness. "Always BE" accesses are easy -- they should be done with the versions of the ld/st functions which have _be_ in them. If there are places using the plain stl_p() functions and assuming they're bigendian, they should be fixed. thanks -- PMM
