Re: [Qemu-devel] [PATCH v3 10/11] tcg-mips: Adjust qemu_ld/st for mips64

[Richard Henderson]

On 11/27/2016 10:59 PM, Jin Guojie wrote:
> In Richard's v2 patch (shown as below), the compilation on mips64 host is 
> disabled.
> 
> -#define LO_OFF    (MIPS_BE * 4)
> -#define HI_OFF    (4 - LO_OFF)
> +#if TCG_TARGET_REG_BITS == 32
> +# define LO_OFF  (MIPS_BE * 4)
> +# define HI_OFF  (4 - LO_OFF)
> +#else
> +extern int link_error(void);
> +# define LO_OFF  link_error()
> +# define HI_OFF  link_error()
> +#endif
> 
> When I compiled this patch on Loongson as mips64el, a link error occured:
> 
>   LINK    i386-softmmu/qemu-system-i386
> tcg/tcg.o: In function `tcg_out_tlb_load':
> tcg-target.inc.c:1252: undefined reference to `link_error'

The intent of the link_error is to ensure that all paths that lead to the use
of the symbol are eliminated by the compiler.  Therefore all uses must be
protected by some trivially eliminated condition like

  TCG_TARGET_REG_BITS < TARGET_LONG_BITS

which can only be true for 32-bit host and 64-bit guest.

Within the code that I have here, I only see two uses of LO/HI_OFF within
tcg_out_tlb_load, both of which are protected by this condition.

     /* Load the (low half) tlb comparator.  Mask the page bits, keeping the
        alignment bits to compare against.  */
     if (TCG_TARGET_REG_BITS < TARGET_LONG_BITS) {
         tcg_out_ld(s, TCG_TYPE_I32, TCG_TMP0, TCG_REG_A0, cmp_off + LO_OFF);
         tcg_out_movi(s, TCG_TYPE_I32, TCG_TMP1, mask);
...
     /* Load and test the high half tlb comparator.  */
     if (TCG_TARGET_REG_BITS < TARGET_LONG_BITS) {
         /* delay slot */
         tcg_out_ld(s, TCG_TYPE_I32, TCG_TMP0, TCG_REG_A0, cmp_off + HI_OFF);

The line numbers don't match up with what you quote, so I'm curious exactly
which use is generating the error.


> Frankly speaking, I didn't take n32 into consideration until you pointed out 
> that.
> I feel that n32 is rarely used in current and future market. I can not even 
> find an n32 
> debian distribution in Aurelien's qemu image collection.
> How about leave n32 as a TODO feature?

You're probably right.  Especially in the case of qemu, we really want the host
to have a 64-bit virtual address space within which we can store the guest
memory.  The 2G available to N32 is only good for really small guests.

In this case, however, it seems just as easy to get it right, since we can test
this code with N64.


r~