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

[Mark Millard via freebsd-ports]

On 2018-Nov-4, at 1:06 AM, Thomas Zander  wrote:

> On Fri, 1 Sep 2017 at 01:37, Mark Millard  wrote:
> 
>> [I show some of the target/ppc/translate.c source code
>> and related material this time. Not that I know enough
>> to patch it correctly.]
> 
> This is still an issue, correct?
> I tried to create a powerpc poudriere jail on 11.2 earlier today, with
> the same results.

Last I looked into it: unchanged. Your result tends to confirm the
status is unchanged.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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

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

[Mark Millard]

[I show some of the target/ppc/translate.c source code
and related material this time. Not that I know enough
to patch it correctly.]

On 2017-Aug-31, at 12:13 PM, Mark Millard  wrote:

> [Turns out that the emulated program counter is not progressing
> for syscall emulation, at least for [some] syscall [failure] cases.]
> 
> On 2017-Aug-30, at 8:43 PM, Mark Millard  wrote:
> 
>> On 2017-Aug-30, at 4:32 PM, Don Lewis  wrote:
>> 
>>> On 30 Aug, Mark Millard wrote:
 On 2017-Aug-30, at 4:00 AM, Mark Linimon  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_READLINKSTD { ssize_t readlink(char *path, char *buf, \
 size_t count); }
 
 As confirmed by (note the "callq  0x60207360 " ):
 
 (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 0x60045d3e
 => 0x60045d3e :   callq  0x6004fd20 
 
 0x60045d43 :  test   %rax,%rax
 0x60045d46 :  js 0x6004b99c 
 
 0x60045d4c :  inc%rax
 0x60045d4f :  mov$0x1,%edx
 0x60045d54 :  mov%rbx,%rdi
 0x60045d57 :  mov%rax,%rsi
 0x60045d5a :  callq  0x6003c430 
 
 0x60045d5f :  test   %eax,%eax
 0x60045d61 :  jne0x6004bce4 
 
 0x60045d67 :  add0x26d91b2(%rip),%rbx 
# 0x6271ef20 
 0x60045d6e :  je 0x6004bce4 
 
 0x60045d74 :  mov$0x3,%edx
 0x60045d79 :  mov-0x2a8(%rbp),%r14
 0x60045d80 :  mov%r14,%rdi
 0x60045d83 :  mov%r12,%rsi
 0x60045d86 :  callq  0x6003c430 
 
 0x60045d8b :  test   %eax,%eax
 0x60045d8d :  jne0x6004bce4 
 
 0x60045d93 :  add0x26d9186(%rip),%r14 
# 0x6271ef20 
 0x60045d9a :  mov-0x294(%rbp),%r10d
 0x60045da1 :  mov$0xfff2,%r13
 0x60045da8 :  je 0x6004bcf2 
 
 0x60045dae :  mov$0x602b93da,%esi
 0x60045db3 :  mov%rbx,%rdi
 0x60045db6 :  callq  0x60230af0 
 0x60045dbb :  test   %eax,%eax
 0x60045dbd :  je 0x6004c566 
 
 0x60045dc3 :  mov%rbx,%rdi
 0x60045dc6 :  callq  0x60158660 
 0x60045dcb :  mov%rax,%rdi
 0x60045dce :  mov%r14,%rsi
 0x60045dd1 :  mov%r12,%rdx
 0x60045dd4 :  callq  0x60207360 
 
 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 

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

[Mark Millard]

[Just adding Sean Bruno in case the information is new to him.
I top post a note for that.]

Sean: The below reports on what I've found for what is
happening for qemu-ppc64-static (and possibly others) when
it gets stuck eating CPU time (and leaking memory), at least
for the example I ran into (that basically blocks all use
of qemu-ppc64-static it happens very early in all(?)
attempted uses that load.

The content reflects my exploration order. The summary is:

A) I've found an example context where the emulated
pc does not progress and it ends up looping repeating
a syscall.

B) Given that is involved: I've found that env->gpr[3]
handling for failed syscall attempts contributes to the
detailed failure behaviors. (This part is, of course,
likely very powerpc specific.)


But I found (B) before finding (A) as its context and
(A) might be the only problem for all I know: having the
emulated program counter progress correctly might end
up dealing with env->gpr[3] correctly in the newly
executed code.

At this point I've no clue where the emulated PC should
be adjusted in the code or what the detailed adjustment
rules should be for the context, only that the PC is not
being adjusted now but needs to be adjusted.

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

On 2017-Aug-31, at 12:13 PM, Mark Millard  wrote:

[Turns out that the emulated program counter is not progressing
for syscall emulation, at least for [some] syscall [failure] cases.]

On 2017-Aug-30, at 8:43 PM, Mark Millard  wrote:

> On 2017-Aug-30, at 4:32 PM, Don Lewis  wrote:
> 
>> On 30 Aug, Mark Millard wrote:
>>> On 2017-Aug-30, at 4:00 AM, Mark Linimon  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_READLINKSTD { ssize_t readlink(char *path, char *buf, \
>>>  size_t count); }
>>> 
>>> As confirmed by (note the "callq  0x60207360 " ):
>>> 
>>> (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 0x60045d3e
>>> => 0x60045d3e :callq  0x6004fd20 
>>> 
>>> 0x60045d43 :   test   %rax,%rax
>>> 0x60045d46 :   js 0x6004b99c 
>>> 
>>> 0x60045d4c :   inc%rax
>>> 0x60045d4f :   mov$0x1,%edx
>>> 0x60045d54 :   mov%rbx,%rdi
>>> 0x60045d57 :   mov%rax,%rsi
>>> 0x60045d5a :   callq  0x6003c430 
>>> 
>>> 0x60045d5f :   test   %eax,%eax
>>> 0x60045d61 :   jne0x6004bce4 
>>> 
>>> 0x60045d67 :   add0x26d91b2(%rip),%rbx 
>>># 0x6271ef20 
>>> 0x60045d6e :   je 0x6004bce4 
>>> 
>>> 0x60045d74 :   mov$0x3,%edx
>>> 0x60045d79 :   mov-0x2a8(%rbp),%r14
>>> 0x60045d80 :   mov%r14,%rdi
>>> 0x60045d83 :   mov%r12,%rsi
>>> 0x60045d86 :   callq  0x6003c430 
>>> 
>>> 0x60045d8b :   test   %eax,%eax
>>> 0x60045d8d :   jne0x6004bce4 
>>> 
>>> 0x60045d93 :   add0x26d9186(%rip),%r14 
>>># 0x6271ef20 
>>> 0x60045d9a :   mov-0x294(%rbp),%r10d
>>> 0x60045da1 :   mov$0xfff2,%r13
>>> 0x60045da8 :   je 0x6004bcf2 
>>> 
>>> 0x60045dae :   mov$0x602b93da,%esi
>>> 0x60045db3 :   mov%rbx,%rdi
>>> 0x60045db6 :   callq  0x60230af0 
>>> 0x60045dbb :   

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

[Mark Millard]

[Turns out that the emulated program counter is not progressing
for syscall emulation, at least for syscall falure cases.]

On 2017-Aug-30, at 8:43 PM, Mark Millard  wrote:

> On 2017-Aug-30, at 4:32 PM, Don Lewis  wrote:
> 
>> On 30 Aug, Mark Millard wrote:
>>> On 2017-Aug-30, at 4:00 AM, Mark Linimon  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_READLINKSTD { ssize_t readlink(char *path, char *buf, \
>>>   size_t count); }
>>> 
>>> As confirmed by (note the "callq  0x60207360 " ):
>>> 
>>> (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 0x60045d3e
>>> => 0x60045d3e :callq  0x6004fd20 
>>> 
>>>  0x60045d43 :  test   %rax,%rax
>>>  0x60045d46 :  js 0x6004b99c 
>>> 
>>>  0x60045d4c :  inc%rax
>>>  0x60045d4f :  mov$0x1,%edx
>>>  0x60045d54 :  mov%rbx,%rdi
>>>  0x60045d57 :  mov%rax,%rsi
>>>  0x60045d5a :  callq  0x6003c430 
>>> 
>>>  0x60045d5f :  test   %eax,%eax
>>>  0x60045d61 :  jne0x6004bce4 
>>> 
>>>  0x60045d67 :  add0x26d91b2(%rip),%rbx 
>>># 0x6271ef20 
>>>  0x60045d6e :  je 0x6004bce4 
>>> 
>>>  0x60045d74 :  mov$0x3,%edx
>>>  0x60045d79 :  mov-0x2a8(%rbp),%r14
>>>  0x60045d80 :  mov%r14,%rdi
>>>  0x60045d83 :  mov%r12,%rsi
>>>  0x60045d86 :  callq  0x6003c430 
>>> 
>>>  0x60045d8b :  test   %eax,%eax
>>>  0x60045d8d :  jne0x6004bce4 
>>> 
>>>  0x60045d93 :  add0x26d9186(%rip),%r14 
>>># 0x6271ef20 
>>>  0x60045d9a :  mov-0x294(%rbp),%r10d
>>>  0x60045da1 :  mov$0xfff2,%r13
>>>  0x60045da8 :  je 0x6004bcf2 
>>> 
>>>  0x60045dae :  mov$0x602b93da,%esi
>>>  0x60045db3 :  mov%rbx,%rdi
>>>  0x60045db6 :  callq  0x60230af0 
>>>  0x60045dbb :  test   %eax,%eax
>>>  0x60045dbd :  je 0x6004c566 
>>> 
>>>  0x60045dc3 :  mov%rbx,%rdi
>>>  0x60045dc6 :  callq  0x60158660 
>>>  0x60045dcb :  mov%rax,%rdi
>>>  0x60045dce :  mov%r14,%rsi
>>>  0x60045dd1 :  mov%r12,%rdx
>>>  0x60045dd4 :  callq  0x60207360 
>>> 
>>> 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.
> 
> I've been using -w right along. But I'd not used testport at all.
> 
> It looks to me like the syscall errno handling is messed
> 

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

[Mark Millard]

On 2017-Aug-30, at 4:32 PM, Don Lewis  wrote:

> On 30 Aug, Mark Millard wrote:
>> On 2017-Aug-30, at 4:00 AM, Mark Linimon  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_READLINKSTD { ssize_t readlink(char *path, char *buf, \
>>size_t count); }
>> 
>> As confirmed by (note the "callq  0x60207360 " ):
>> 
>> (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 0x60045d3e
>> => 0x60045d3e : callq  0x6004fd20 
>> 
>>   0x60045d43 :  test   %rax,%rax
>>   0x60045d46 :  js 0x6004b99c 
>> 
>>   0x60045d4c :  inc%rax
>>   0x60045d4f :  mov$0x1,%edx
>>   0x60045d54 :  mov%rbx,%rdi
>>   0x60045d57 :  mov%rax,%rsi
>>   0x60045d5a :  callq  0x6003c430 
>> 
>>   0x60045d5f :  test   %eax,%eax
>>   0x60045d61 :  jne0x6004bce4 
>> 
>>   0x60045d67 :  add0x26d91b2(%rip),%rbx 
>># 0x6271ef20 
>>   0x60045d6e :  je 0x6004bce4 
>> 
>>   0x60045d74 :  mov$0x3,%edx
>>   0x60045d79 :  mov-0x2a8(%rbp),%r14
>>   0x60045d80 :  mov%r14,%rdi
>>   0x60045d83 :  mov%r12,%rsi
>>   0x60045d86 :  callq  0x6003c430 
>> 
>>   0x60045d8b :  test   %eax,%eax
>>   0x60045d8d :  jne0x6004bce4 
>> 
>>   0x60045d93 :  add0x26d9186(%rip),%r14 
>># 0x6271ef20 
>>   0x60045d9a :  mov-0x294(%rbp),%r10d
>>   0x60045da1 :  mov$0xfff2,%r13
>>   0x60045da8 :  je 0x6004bcf2 
>> 
>>   0x60045dae :  mov$0x602b93da,%esi
>>   0x60045db3 :  mov%rbx,%rdi
>>   0x60045db6 :  callq  0x60230af0 
>>   0x60045dbb :  test   %eax,%eax
>>   0x60045dbd :  je 0x6004c566 
>> 
>>   0x60045dc3 :  mov%rbx,%rdi
>>   0x60045dc6 :  callq  0x60158660 
>>   0x60045dcb :  mov%rax,%rdi
>>   0x60045dce :  mov%r14,%rsi
>>   0x60045dd1 :  mov%r12,%rdx
>>   0x60045dd4 :  callq  0x60207360 
>> 
>> 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.

I've been using -w right along. But I'd not used testport at all.

It looks to me like the syscall errno handling is messed
up. The details that I've observed follow. It follows
a simplified sequence of discovery as far a presentation
order goes.

The looping code is:

static inline void target_cpu_loop(CPUPPCState *env)
{
CPUState *cs = CPU(ppc_env_get_cpu(env));
  

Re: 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  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_READLINKSTD { ssize_t readlink(char *path, char *buf, \
> size_t count); }
> 
> As confirmed by (note the "callq  0x60207360 " ):
> 
> (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 0x60045d3e
> => 0x60045d3e :  callq  0x6004fd20 
> 
>0x60045d43 :  test   %rax,%rax
>0x60045d46 :  js 0x6004b99c 
> 
>0x60045d4c :  inc%rax
>0x60045d4f :  mov$0x1,%edx
>0x60045d54 :  mov%rbx,%rdi
>0x60045d57 :  mov%rax,%rsi
>0x60045d5a :  callq  0x6003c430 
> 
>0x60045d5f :  test   %eax,%eax
>0x60045d61 :  jne0x6004bce4 
> 
>0x60045d67 :  add0x26d91b2(%rip),%rbx 
># 0x6271ef20 
>0x60045d6e :  je 0x6004bce4 
> 
>0x60045d74 :  mov$0x3,%edx
>0x60045d79 :  mov-0x2a8(%rbp),%r14
>0x60045d80 :  mov%r14,%rdi
>0x60045d83 :  mov%r12,%rsi
>0x60045d86 :  callq  0x6003c430 
> 
>0x60045d8b :  test   %eax,%eax
>0x60045d8d :  jne0x6004bce4 
> 
>0x60045d93 :  add0x26d9186(%rip),%r14 
># 0x6271ef20 
>0x60045d9a :  mov-0x294(%rbp),%r10d
>0x60045da1 :  mov$0xfff2,%r13
>0x60045da8 :  je 0x6004bcf2 
> 
>0x60045dae :  mov$0x602b93da,%esi
>0x60045db3 :  mov%rbx,%rdi
>0x60045db6 :  callq  0x60230af0 
>0x60045dbb :  test   %eax,%eax
>0x60045dbd :  je 0x6004c566 
> 
>0x60045dc3 :  mov%rbx,%rdi
>0x60045dc6 :  callq  0x60158660 
>0x60045dcb :  mov%rax,%rdi
>0x60045dce :  mov%r14,%rsi
>0x60045dd1 :  mov%r12,%rdx
>0x60045dd4 :  callq  0x60207360 
> 
> 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.

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

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

[Mark Linimon]

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.)

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

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

[Mark Millard]

qemu-ppc64-static and qemu-ppc-static "live-hang" when I
attempt use them with poudriere, hanging at the command
(showing an example process id):

/usr/local/bin/qemu-ppc-static /bin/ps -ww -p 47841 -o jid=

which eats CPU time and grows memory SIZE over time.
Examples from after waiting a while in each case:

  PID USERNAMETHR PRI NICE   SIZERES   SWAP STATE   C   TIME CPU 
COMMAND
48319 root  2 1030  8413M   234M 0K CPU11  11   2:50 101.97% 
/usr/local/bin/qemu-ppc64-static /bin/ps -ww -p 48318 -o jid

  PID USERNAMETHR PRI NICE   SIZERES   SWAP STATE   C   TIME CPU 
COMMAND
47842 root  2 1030 16597M   455M 0K CPU11   5:25  96.38% 
/usr/local/bin/qemu-ppc-static /bin/ps -ww -p 47841 -o jid=


By contrast I've no such problem with qemu-arm-static or
qemu-aarch64-static : these were able to build lang/gcc7
(full bootstrap) in between 4 and 5 hours hours each,
the prerequisites also being built in the process.

# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 448068
Last Changed Rev: 448068



My attempts to manually use qemu-ppc64-static and qemu-ppc-static
(with -L supplied) also get such results. The same for
qemu-ppc*-static running a statically linked rescue program (so
no -L needed).

It appears that qemu-ppc64-static and qemu-ppc-static from
emulators/qemu-user-static are broken.

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

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

Re: qemu-aarch64-static

[Luca Pizzamiglio]

If you want to cross-compile, you need
* a proper toolchain
* a project that's enable to produce cross-compiled binaries


On Tue, Aug 22, 2017 at 8:04 PM, Andrea Venturoli  wrote:
> On 08/22/17 18:03, Luca Pizzamiglio wrote:
>>
>> yes, the qemu emulation of other architecture means that the CPU is
>> emulated by software, that's really expensive.
>> You should consider around 10x slower or even more. ccache can help a
>> lot in this case.
>
>
> Thanks.
> So you are confirming my poudriere is running an ARM compiler to produce ARM
> code?

I've played with cross-compile in the past and that's my understanding.

>
> What's the use of "-x" when creating a jail then?
> What role does the "native cross-toolchain" play?

The FreeBSD jail is built using a cross-toolchain (fast) and it
contains "cross-binaries" (in case of ARM, in the jail you will have a
compiler which host and target are ARM)
The packages are built inside a "cross-jail" (slow)

The problem is that external ports often don't support cross-compile,
so instead of modify tons of ports to add cross-tollchain support,
poudriere/FreeBSD exploit features offered by binmisc/qemu to build
binaries in a emulated environment. The big drawback is the speed.

> I understood that would mean running an AMD64 compiler to cross-build ARM
> code... and thought that its timings would be comparable to native building.
> Is that wrong?
>
>  bye & Thanks
> av.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: qemu-aarch64-static

[Jan Beich]

Andrea Venturoli  writes:

> On 08/17/17 21:22, Jan Beich wrote:
>> That page is a bit out of date. Nowadays building for aarch64 is as simple as
>>
>>$ pkg install poudriere qemu-user-static
>>$ service qemu_user_static onestart
>>$ poudriere jail -cj 111aarch64 -a arm64.aarch64 -v 11.1-RELEASE
>>$ poudriere bulk -j 111aarch64 category/port
>
> I can confirm this is working.

To upgrade above jail to native-xtools try

  $ svn co https://svn.freebsd.org/base/releng/11.1 /usr/src
  $ poudriere jail -uj 111aarch64 -x

or create a new jail e.g.,

  $ svn co https://svn.freebsd.org/base/releng/11.1 /usr/src
  $ poudriere jail -cj 111armv6 -x -a arm.armv6 -v releng/11.1 -m svn

>
>> To speed up port builds you may want to consider using native
>> cross-toolchain by creating a jail with -x flag.
>
> Do you have any more info on this?

Nah. native-xtools was briefly mentioned in poudriere-3.1 changelog and
a bit more on EuroBSDCon 2014. I didn't try -x myself until recently.

https://www.youtube.com/watch?v=2J9Lz3pgnbA
https://www.youtube.com/watch?v=JfZIoyQhly4

> Except from poudriere's man page's description I could find no other
> docs. Is there any more elaborate description on what this does and
> how?

poudriere builds native-xtools target under /usr/src, installs it under
/nxb-bin prefix then prepends it via PATH when building ports. For a living
example see armv6 and mips* builders on pkg-status.freebsd.org e.g.,

http://beefy8.nyi.freebsd.org/data/head-armv6-default/p448278_s322683/logs/nasm-2.13.01,1.log

> I built the jail with -x, but how do I check it's using "native-xtools"?

Check /nxb-bin exists and isn't empty e.g.,

  $ file /poudriere/jails/111aarch64/nxb-bin/usr/bin/cc
  /poudriere/jails/111aarch64/nxb-bin/usr/bin/cc: ELF 64-bit LSB executable, 
x86-64, version 1 (FreeBSD), statically linked, for FreeBSD 12.0 (1200040), 
FreeBSD-style, not stripped

  $ /poudriere/jails/111aarch64/nxb-bin/usr/bin/cc -v
  FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 
4.0.0)
  Target: aarch64-unknown-freebsd11.1
  Thread model: posix
  InstalledDir: /poudriere/jails/111aarch64/nxb-bin/usr/bin
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: qemu-aarch64-static

[Andrea Venturoli]

On 08/22/17 18:03, Luca Pizzamiglio wrote:

yes, the qemu emulation of other architecture means that the CPU is
emulated by software, that's really expensive.
You should consider around 10x slower or even more. ccache can help a
lot in this case.


Thanks.
So you are confirming my poudriere is running an ARM compiler to produce 
ARM code?


What's the use of "-x" when creating a jail then?
What role does the "native cross-toolchain" play?
I understood that would mean running an AMD64 compiler to cross-build 
ARM code... and thought that its timings would be comparable to native 
building.

Is that wrong?

 bye & Thanks
av.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: qemu-aarch64-static

[Luca Pizzamiglio]

yes, the qemu emulation of other architecture means that the CPU is
emulated by software, that's really expensive.
You should consider around 10x slower or even more. ccache can help a
lot in this case.

Best regards,
Luca


On Tue, Aug 22, 2017 at 7:40 AM, Andrea Venturoli  wrote:
> On 08/17/17 21:22, Jan Beich wrote:
>
>> Yep. Link the binary (i.e. "date") statically or run it inside
>> jail/chroot.
>> Otherwise, /libexec/ld-elf.so.1 references the host system, which on amd64
>> wouldn't recognize aarch64 shared libraries.
>
>
> Thanks a lot.
> Now it seems so obvious to me, but I really wouldn't have thought about this
> little detail :)
>
>
>
>> That page is a bit out of date. Nowadays building for aarch64 is as simple
>> as
>>
>>$ pkg install poudriere qemu-user-static
>>$ service qemu_user_static onestart
>>$ poudriere jail -cj 111aarch64 -a arm64.aarch64 -v 11.1-RELEASE
>>$ poudriere bulk -j 111aarch64 category/port
>
>
> I can confirm this is working.
>
>
>
>> To speed up port builds you may want to consider using native
>> cross-toolchain by creating a jail with -x flag.
>
>
> Do you have any more info on this?
> Except from poudriere's man page's description I could find no other docs.
> Is there any more elaborate description on what this does and how?
>
> I built the jail with -x, but how do I check it's using "native-xtools"?
>
> I tried building ports-mgmt/pkg and it requires ten times more than native
> build (i.e. 24 minutes for aarch64 vs. less than 3 minutes for amd64). Is
> this normal?
>
>
>
>  bye & Thanks
> av.
>
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: qemu-aarch64-static

[Andrea Venturoli]

On 08/17/17 21:22, Jan Beich wrote:


Yep. Link the binary (i.e. "date") statically or run it inside jail/chroot.
Otherwise, /libexec/ld-elf.so.1 references the host system, which on amd64
wouldn't recognize aarch64 shared libraries.


Thanks a lot.
Now it seems so obvious to me, but I really wouldn't have thought about 
this little detail :)





That page is a bit out of date. Nowadays building for aarch64 is as simple as

   $ pkg install poudriere qemu-user-static
   $ service qemu_user_static onestart
   $ poudriere jail -cj 111aarch64 -a arm64.aarch64 -v 11.1-RELEASE
   $ poudriere bulk -j 111aarch64 category/port


I can confirm this is working.




To speed up port builds you may want to consider using native
cross-toolchain by creating a jail with -x flag.


Do you have any more info on this?
Except from poudriere's man page's description I could find no other 
docs. Is there any more elaborate description on what this does and how?


I built the jail with -x, but how do I check it's using "native-xtools"?

I tried building ports-mgmt/pkg and it requires ten times more than 
native build (i.e. 24 minutes for aarch64 vs. less than 3 minutes for 
amd64). Is this normal?




 bye & Thanks
av.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: qemu-aarch64-static

[Jan Beich]

(Redirected from 
https://lists.freebsd.org/pipermail/freebsd-questions/2017-August/278443.html )

Andrea Venturoli  writes:

>> # file date
>> date: ELF 64-bit MSB executable, MIPS, MIPS-III version 1 (FreeBSD),
>> statically linked, FreeBSD-style, for FreeBSD 10.0 (127),
>> stripped
>> # ./date Thu Aug 17 19:51:56 CEST 2017
>
>> # file date
>> date: ELF 64-bit LSB executable, ARM aarch64, version 1 (FreeBSD),
>> dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD
>> 11.1, FreeBSD-style, not stripped
>> # ./date
>> Unable to load interpreter
>
> Is this the expected behaviour?

Yep. Link the binary (i.e. "date") statically or run it inside jail/chroot.
Otherwise, /libexec/ld-elf.so.1 references the host system, which on amd64
wouldn't recognize aarch64 shared libraries.

> I read, on https://wiki.freebsd.org/QemuUserModeHowTo, that "Currently
> only "TARGET=mips TARGET_ARCH=mips64 and "TARGET=arm
> TARGET_ARCH=armv6" has enough machine dependent code in place to do
> everything described below", but OTOH it seems people are using
> poudriere to cross build aarch64 ports (which is what I'd like to do).

That page is a bit out of date. Nowadays building for aarch64 is as simple as

  $ pkg install poudriere qemu-user-static
  $ service qemu_user_static onestart
  $ poudriere jail -cj 111aarch64 -a arm64.aarch64 -v 11.1-RELEASE
  $ poudriere bulk -j 111aarch64 category/port

To speed up port builds you may want to consider using native
cross-toolchain by creating a jail with -x flag.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"