Re: [Qemu-devel] [PATCH 1/5] configure: move TARGET_*_ALIGNMENT to target-*/cpu.h

[Paolo Bonzini <pbonzini@redhat.com>]

Il 02/04/2013 19:17, Peter Maydell ha scritto:
> On 2 April 2013 17:56, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Il 02/04/2013 18:43, Peter Maydell ha scritto:
>>> Doesn't this incorrectly set the long alignment to 8
>>> for ppc64abi32? (Probably similar problem for
>>> sparc32plus and mipsn32. The underlying point here is that
>>> alignment is an ABI decision and you can have more than one
>>> ABI for a particular TARGET_FOO.)
>>
>> Hmm, seems like you're right _but_ I am not sure if the *current* code
>> is correct.  On real hardware, the CPUs are certainly not able to do
>> unaligned 32-bit accesses, and target_long/target_ulong pointers look
>> like they're never used for data that comes from target memory.
> 
> Did you check linux-user too? I'm pretty sure we have structs
> and so on that mirror target memory and use target_ulong.
> 
>> What these targets want to have 32-bit alignment is really
>> abi_long/abi_ulong, and that's already okay. Alex, Blue, Aurelien,
>> can you test the above three targets?
> 
> Mmm, rather than speculating we should just confirm what gcc
> thinks the alignment of void* should be on these targets
> (since "a thing the size of a pointer" is what target_long/ulong
> represent, I think.)

I think "a thing the size of a pointer" should be abi_long/ulong.  The
pointer is not a CPU concept.

> That said, we should keep bugfixes and cleanup patches separated,

Indeed.  The change was unintended, and your comment is worth a respin.

> so on approach for proceeding with these cleanup patches is just
> to define TARGET_LONG_ALIGNMENT based on TARGET_ABI32 or whatever is
> appropriate for each target CPU. Then we retain the same behaviour.

Yes, TARGET_ABI32.  I'll have to squash patches 1 and 2, and the testing
RFH still holds because this alignment things sounds fishy...

Paolo