On 2017-Aug-30, at 4:00 AM, Mark Linimon <lini...@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:

 STRIP_CMD=     ${TRUE}
 .endif
 DEBUG_FLAGS?=  -g
+.if defined(ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG)
+CFLAGS:=               ${CFLAGS} ${DEBUG_FLAGS}
+.else
 CFLAGS:=               ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS}
+.endif
 .if defined(INSTALL_TARGET)
 INSTALL_TARGET:=       ${INSTALL_TARGET:S/^install-strip$/install/g}
 .endif

mixed with make.conf indicating to use the
new alternative:

WANT_QT_VERBOSE_CONFIGURE=1
#
DEFAULT_VERSIONS+=perl5=5.24 gcc=7
#
# From a local /usr/ports/Mk/bsd.port.mk extension:
ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG=
#
.if ${.CURDIR:M*/devel/llvm*}
#WITH_DEBUG=
.elif ${.CURDIR:M*/www/webkit-qt5*}
#WITH_DEBUG=
.else
WITH_DEBUG=
.endif
MALLOC_PRODUCTION=


I got as much information as I report
above via use of:

/usr/local/bin/gdb /usr/local/bin/qemu-user-static

and then:

run /usr/obj/DESTDIRs/clang-powerpc64-installworld-dist-from-src/rescue/id

and then interrupting it and exploring.

===
Mark Millard
markmi at dsl-only.net

_______________________________________________
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Reply via email to