FYI: qemu-ppc64-static and qemu-ppc-static "live-hang" when I attempt use with poudriere; qemu-arm-static and qemu-aarch64-static work

[Don Lewis]

On 30 Aug, Mark Millard wrote:
> On 2017-Aug-30, at 4:00 AM, Mark Linimon <linimon at lonesome.com> wrote:
> 
>> On Wed, Aug 30, 2017 at 03:09:40AM -0700, Mark Millard wrote:
>>> It appears that qemu-ppc64-static and qemu-ppc-static from
>>> emulators/qemu-user-static are broken.
>> 
>> Correct, and known for some time.  (fwiw sparc64 hangs as well.)
> 
> Looks like qemu-ppc64-static is stuck in a loop, calling
> repeatedly:
> 
> do_freebsd_syscall (cpu_env=0x860ea3ac0, num=58, arg1=14, arg2=35995509911, arg3=1024, arg4=268435904, arg5=281494784, arg6=35985701568, arg7=515, arg8=35985668288)
>     at /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/syscall.c:210
> 210	/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/syscall.c: No such file or directory.
> 
> Which is for:
> 
> 58      AUE_READLINK    STD     { ssize_t readlink(char *path, char *buf, \
>                                     size_t count); }
> 
> As confirmed by (note the "callq  0x60207360 <readlink>" ):
> 
> (gdb) 
> lock_user_string (guest_addr=14) at /wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/qemu.h:508
> 508	/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-17977d0/bsd-user/qemu.h: No such file or directory.
> 
> (gdb) x/64i 0x0000000060045d3e
> => 0x60045d3e <do_freebsd_syscall+3246>:	callq  0x6004fd20 <target_strlen>
>    0x60045d43 <do_freebsd_syscall+3251>:	test   %rax,%rax
>    0x60045d46 <do_freebsd_syscall+3254>:	js     0x6004b99c <do_freebsd_syscall+26892>
>    0x60045d4c <do_freebsd_syscall+3260>:	inc    %rax
>    0x60045d4f <do_freebsd_syscall+3263>:	mov    $0x1,%edx
>    0x60045d54 <do_freebsd_syscall+3268>:	mov    %rbx,%rdi
>    0x60045d57 <do_freebsd_syscall+3271>:	mov    %rax,%rsi
>    0x60045d5a <do_freebsd_syscall+3274>:	callq  0x6003c430 <page_check_range>
>    0x60045d5f <do_freebsd_syscall+3279>:	test   %eax,%eax
>    0x60045d61 <do_freebsd_syscall+3281>:	jne    0x6004bce4 <do_freebsd_syscall+27732>
>    0x60045d67 <do_freebsd_syscall+3287>:	add    0x26d91b2(%rip),%rbx        # 0x6271ef20 <guest_base>
>    0x60045d6e <do_freebsd_syscall+3294>:	je     0x6004bce4 <do_freebsd_syscall+27732>
>    0x60045d74 <do_freebsd_syscall+3300>:	mov    $0x3,%edx
>    0x60045d79 <do_freebsd_syscall+3305>:	mov    -0x2a8(%rbp),%r14
>    0x60045d80 <do_freebsd_syscall+3312>:	mov    %r14,%rdi
>    0x60045d83 <do_freebsd_syscall+3315>:	mov    %r12,%rsi
>    0x60045d86 <do_freebsd_syscall+3318>:	callq  0x6003c430 <page_check_range>
>    0x60045d8b <do_freebsd_syscall+3323>:	test   %eax,%eax
>    0x60045d8d <do_freebsd_syscall+3325>:	jne    0x6004bce4 <do_freebsd_syscall+27732>
>    0x60045d93 <do_freebsd_syscall+3331>:	add    0x26d9186(%rip),%r14        # 0x6271ef20 <guest_base>
>    0x60045d9a <do_freebsd_syscall+3338>:	mov    -0x294(%rbp),%r10d
>    0x60045da1 <do_freebsd_syscall+3345>:	mov    $0xfffffffffffffff2,%r13
>    0x60045da8 <do_freebsd_syscall+3352>:	je     0x6004bcf2 <do_freebsd_syscall+27746>
>    0x60045dae <do_freebsd_syscall+3358>:	mov    $0x602b93da,%esi
>    0x60045db3 <do_freebsd_syscall+3363>:	mov    %rbx,%rdi
>    0x60045db6 <do_freebsd_syscall+3366>:	callq  0x60230af0 <strcmp>
>    0x60045dbb <do_freebsd_syscall+3371>:	test   %eax,%eax
>    0x60045dbd <do_freebsd_syscall+3373>:	je     0x6004c566 <do_freebsd_syscall+29910>
>    0x60045dc3 <do_freebsd_syscall+3379>:	mov    %rbx,%rdi
>    0x60045dc6 <do_freebsd_syscall+3382>:	callq  0x60158660 <path>
>    0x60045dcb <do_freebsd_syscall+3387>:	mov    %rax,%rdi
>    0x60045dce <do_freebsd_syscall+3390>:	mov    %r14,%rsi
>    0x60045dd1 <do_freebsd_syscall+3393>:	mov    %r12,%rdx
>    0x60045dd4 <do_freebsd_syscall+3396>:	callq  0x60207360 <readlink>
> 
> But note that the "lock_user_string (guest_addr=14)" and
> "do_freebsd_syscall (cpu_env=0x860ea3ac0, num=58, arg1=14,"
> indicate that the "readlink(char *path," is using a really
> small address for the path string.
> 
> 
> I've not figured a way for poudriere bulk builds to leave
> behind the source code automatically. So far I've not
> looked at the qemu-bsd-user source code. I do build with
> both debug and optimization turned on via bsd.port.mk
> having:

The -w option will create a tarball of the work directory if the
package build fails.  I also often use the testport -i option I want to
poke around in the WRKDIR after a build.