Re: [Qemu-devel] [PULL 00/26] New hppa-linux target support

[Peter Maydell]

On 23 January 2017 at 02:17, Richard Henderson <address@hidden> wrote:
> This is a linux-user only port, emulating a 32-bit only version of a
> pa-2.0 cpu.  This is good enough to do well with both the gcc and glibc
> testsuites.  Helge Deller has provided invaluable assistance testing
> with a more complete debian chroot.
>
> What's missing:
>   * Space registers.  Since Linux sets them all equal (for a flat
>     address space) and uses them like address-space identifiers,
>     we can simply set them all to 0 and ignore them.
>
>   * Architecture subsets.  There's no markup for running a pure pa1.0
>     or pa1.1 cpu.  I happily accept everything up to pa2.0 at the moment.
>
>   * Wide mode.  While I have pa2.0 instructions, I don't support running
>     in 64-bit mode.  Since neither the linux kernel nor glibc support a
>     64-bit userland, it would be a lot more work than just adding the insns.
>
>   * Multimedia instructions.  These are tied to wide mode, so...
>
> When squashing the patches down from my development tree, I wanted to
> preserve Helge's contributions, so the linux-user part is more patches
> than I would normally have preserved.
>
>
> r~
>
>
>
> The following changes since commit d1c82f7cc34443841095f490345f86c9d8baca34:
>
>   Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20170120-v2' into 
> staging (2017-01-20 15:53:58 +0000)
>
> are available in the git repository at:
>
>   git://github.com/rth7680/qemu.git tags/pull-hppa-20170122
>
> for you to fetch changes up to 0ce588d6c60c338c0856b0dac78d19fc7e698477:
>
>   target-hppa: Implement floating-point insns (2017-01-22 18:14:12 -0800)
>
> ----------------------------------------------------------------
> hppa-linux target support
>

Hi; I'm afraid this fails to build on a couple of my test hosts:

PPC64BE host, arm32, aarch64 host:
/home/pm215/qemu/linux-user/syscall.c: In function ‘do_setsockopt’:
/home/pm215/qemu/linux-user/syscall.c:2827:14: error:
‘IPV6_RECVPATHMTU’ undeclared (first use in this function)
         case IPV6_RECVPATHMTU:
              ^
/home/pm215/qemu/linux-user/syscall.c:2827:14: note: each undeclared
identifier is reported only once for each function it appears in
/home/pm215/qemu/linux-user/syscall.c:2828:14: error:
‘IPV6_TRANSPARENT’ undeclared (first use in this function)
         case IPV6_TRANSPARENT:
              ^
/home/pm215/qemu/linux-user/syscall.c:2829:14: error:
‘IPV6_RECVORIGDSTADDR’ undeclared (first use in this function)
         case IPV6_RECVORIGDSTADDR:
              ^
/home/pm215/qemu/linux-user/syscall.c:2833:14: error:
‘IPV6_UNICAST_IF’ undeclared (first use in this function)
         case IPV6_UNICAST_IF:
              ^
/home/pm215/qemu/linux-user/syscall.c:2839:14: error:
‘IPV6_ADDR_PREFERENCES’ undeclared (first use in this function)
         case IPV6_ADDR_PREFERENCES:
              ^
/home/pm215/qemu/linux-user/syscall.c:2840:14: error:
‘IPV6_MINHOPCOUNT’ undeclared (first use in this function)
         case IPV6_MINHOPCOUNT:
              ^
/home/pm215/qemu/linux-user/syscall.c:2841:14: error: ‘IPV6_DONTFRAG’
undeclared (first use in this function)
         case IPV6_DONTFRAG:
              ^
/home/pm215/qemu/linux-user/syscall.c:2842:14: error:
‘IPV6_AUTOFLOWLABEL’ undeclared (first use in this function)
         case IPV6_AUTOFLOWLABEL:
              ^

(same for all targets).

Looking at the systems in question these constants are #defined
in /usr/include/linux/in6.h. The difference from the working x86
host is I think that x86 also defines them in
/usr/include/x86-64-linux-gnu/bits/in.h.
Presumably they're being implicitly dragged in by some other header
and we need to explicitly #include something instead. I'm
not sure what, though.

thanks
-- PMM