Re: [Qemu-arm] [Qemu-devel] Patch for ARM memory barriers and getdent

[Henry Wertz]

Hi Henry; thanks for these patches. Please could you provide
a Signed-off-by: line for them? This says you're happy for us
to apply them to QEMU under our license, and we can't do anything
with them without one. The top part of
https://wiki.qemu.org/Contribute/SubmitAPatch
has more detail.

     Yup, I'll resubmit both in proper format.

You'll probably have better luck if you submit patches as separate
emails rather than all in one -- the set of people who care about

     Can do.

In general, 64-bit binary on a 32-bit host is not supported by linux-user.
Various things are likely to go wrong for anything but the simplest
of guest binaries. You need a 64-bit host to reliably use linux-user
for a 64-bit guest binary.

     I didn't test it very hard, I was only using it to run the couple Android SDK binaries (aapt and friends) that Android Studio runs; these in general open a file or two, process them, write out a result, so they probably are pretty simple guest binaries.  Nevertheless,with this patch these few x86-64 binaries run on 32-bit ARM and (last I checked) 32-bit Intel.
 

I think your change isn't sufficient to handle the "target 32 bits
and host 64 bits" case, because the 64-on-32 code path that you're
using for it uses the guest's buffer size as the size of the
host buffer it allocates to pass to the host syscall.

....

Maybe I'm missing a clever trick?

     As far as I can tell, it makes a "linux_dirent" and "target_dirent" and is pretty careful to calculate rather than assume offsets, and so on as it copies data from one struct to the other.  i didn't look before, but there is in fact a line "assert(count1 + treclen <= count);" that would trigger if the buffer is going to be overflowed.  I think the code may not have even been needed, except that d_type (file type) was moved to the "middle" of the dirent64 struct instead of at the end.

Thanks!

-- Henry