[PATCH 0/5] linux-user: brk/mmap fixes

Akihiko Odaki posted 5 patches 9 months ago
Failed in applying to current master (apply log)
Maintainers: Laurent Vivier <laurent@vivier.eu>
There is a newer version of this series
linux-user/elfload.c |  4 +--
linux-user/mmap.c    |  2 ++
linux-user/syscall.c | 67 +++++++++-----------------------------------
3 files changed, 17 insertions(+), 56 deletions(-)
[PATCH 0/5] linux-user: brk/mmap fixes
Posted by Akihiko Odaki 9 months ago
linux-user was failing on M2 MacBook Air. Digging into the details, I found
several bugs in brk and mmap so here are fixes.

Akihiko Odaki (5):
  linux-user: Unset MAP_FIXED_NOREPLACE for host
  linux-user: Do not call get_errno() in do_brk()
  linux-user: Use MAP_FIXED_NOREPLACE for do_brk()
  linux-user: Do nothing if too small brk is specified
  linux-user: Do not align brk with host page size

 linux-user/elfload.c |  4 +--
 linux-user/mmap.c    |  2 ++
 linux-user/syscall.c | 67 +++++++++-----------------------------------
 3 files changed, 17 insertions(+), 56 deletions(-)

-- 
2.41.0
Re: [PATCH 0/5] linux-user: brk/mmap fixes
Posted by Michael Tokarev 9 months ago
31.07.2023 11:03, Akihiko Odaki wrote:
> linux-user was failing on M2 MacBook Air. Digging into the details, I found
> several bugs in brk and mmap so here are fixes.

There's another work in this area by Helge Deller, have you seen it?
("linux-user: Fix and optimize target memory layout", a v5 already).

FWIW,

/mjt
Re: [PATCH 0/5] linux-user: brk/mmap fixes
Posted by Joel Stanley 9 months ago
On Mon, 31 Jul 2023 at 09:31, Michael Tokarev <mjt@tls.msk.ru> wrote:
>
> 31.07.2023 11:03, Akihiko Odaki wrote:
> > linux-user was failing on M2 MacBook Air. Digging into the details, I found
> > several bugs in brk and mmap so here are fixes.
>
> There's another work in this area by Helge Deller, have you seen it?
> ("linux-user: Fix and optimize target memory layout", a v5 already).

Applying this series fixes the qemu-arm running the static armhf
binary on my ppc64le host that I reported here[1].

Tested-by: Joel Stanley <joel@jms.id.au>

The changes conflict with Helge's patches, so it would be good to work
out which of your changes should be combined with his.

Cheers,

Joel

[1] https://lore.kernel.org/qemu-devel/CACPK8XeyqcEDyyL3Jw2WYWs_gGdtTCf2=Ly04CMgkshSMdj7RA@mail.gmail.com/
Re: [PATCH 0/5] linux-user: brk/mmap fixes
Posted by Akihiko Odaki 9 months ago
On 2023/07/31 19:17, Joel Stanley wrote:
> On Mon, 31 Jul 2023 at 09:31, Michael Tokarev <mjt@tls.msk.ru> wrote:
>>
>> 31.07.2023 11:03, Akihiko Odaki wrote:
>>> linux-user was failing on M2 MacBook Air. Digging into the details, I found
>>> several bugs in brk and mmap so here are fixes.
>>
>> There's another work in this area by Helge Deller, have you seen it?
>> ("linux-user: Fix and optimize target memory layout", a v5 already).
> 
> Applying this series fixes the qemu-arm running the static armhf
> binary on my ppc64le host that I reported here[1].
> 
> Tested-by: Joel Stanley <joel@jms.id.au>

Thanks for testing.

> 
> The changes conflict with Helge's patches, so it would be good to work
> out which of your changes should be combined with his.

I suggest Helge to rebase his change to my series. The below is some 
detailed explanation:

It is almost orthogonal to my series, but patch 2 will conflict with my 
series since it changes how the initial brk is calculated.

Unfortunately I think patch 2 has a bug. Without my patch, do_brk() 
assumes the heap is aligned with the host page size, but the patch does 
not consider the case that the host and target page sizes are different.

My patch makes the heap aligned with the target page size so it will fix 
the bug.

Regards,
Akihiko Odaki

> 
> Cheers,
> 
> Joel
> 
> [1] https://lore.kernel.org/qemu-devel/CACPK8XeyqcEDyyL3Jw2WYWs_gGdtTCf2=Ly04CMgkshSMdj7RA@mail.gmail.com/
Re: [PATCH 0/5] linux-user: brk/mmap fixes
Posted by Helge Deller 9 months ago
On 7/31/23 12:23, Akihiko Odaki wrote:
> On 2023/07/31 19:17, Joel Stanley wrote:
>> On Mon, 31 Jul 2023 at 09:31, Michael Tokarev <mjt@tls.msk.ru> wrote:
>>>
>>> 31.07.2023 11:03, Akihiko Odaki wrote:
>>>> linux-user was failing on M2 MacBook Air. Digging into the details, I found
>>>> several bugs in brk and mmap so here are fixes.
>>>
>>> There's another work in this area by Helge Deller, have you seen it?
>>> ("linux-user: Fix and optimize target memory layout", a v5 already).
>>
>> Applying this series fixes the qemu-arm running the static armhf
>> binary on my ppc64le host that I reported here[1].
> >> [1] https://lore.kernel.org/qemu-devel/CACPK8XeyqcEDyyL3Jw2WYWs_gGdtTCf2=Ly04CMgkshSMdj7RA@mail.gmail.com/
>>
>> Tested-by: Joel Stanley <joel@jms.id.au>
>
> Thanks for testing.
>
>>
>> The changes conflict with Helge's patches, so it would be good to work
>> out which of your changes should be combined with his.
>
> I suggest Helge to rebase his change to my series. The below is some
> detailed explanation:

> It is almost orthogonal to my series, but patch 2 will conflict with
> my series since it changes how the initial brk is calculated.
>
> Unfortunately I think patch 2 has a bug. Without my patch, do_brk()
> assumes the heap is aligned with the host page size, but the patch
> does not consider the case that the host and target page sizes are
> different.
I've included your patches #2 (bugfix) and #3 (cleanup) to my latest
patch series and published it at
https://github.com/hdeller/qemu-hppa/tree/brk-fixes-akihiko

Maybe you and Joel could try it out?

Helge
Re: [PATCH 0/5] linux-user: brk/mmap fixes
Posted by Helge Deller 9 months ago
On 7/31/23 18:47, Helge Deller wrote:
> On 7/31/23 12:23, Akihiko Odaki wrote:
>> On 2023/07/31 19:17, Joel Stanley wrote:
>>> On Mon, 31 Jul 2023 at 09:31, Michael Tokarev <mjt@tls.msk.ru> wrote:
>>>>
>>>> 31.07.2023 11:03, Akihiko Odaki wrote:
>>>>> linux-user was failing on M2 MacBook Air. Digging into the details, I found
>>>>> several bugs in brk and mmap so here are fixes.
>>>>
>>>> There's another work in this area by Helge Deller, have you seen it?
>>>> ("linux-user: Fix and optimize target memory layout", a v5 already).
>>>
>>> Applying this series fixes the qemu-arm running the static armhf
>>> binary on my ppc64le host that I reported here[1].
>> >> [1] https://lore.kernel.org/qemu-devel/CACPK8XeyqcEDyyL3Jw2WYWs_gGdtTCf2=Ly04CMgkshSMdj7RA@mail.gmail.com/
>>>
>>> Tested-by: Joel Stanley <joel@jms.id.au>
>>
>> Thanks for testing.
>>
>>>
>>> The changes conflict with Helge's patches, so it would be good to work
>>> out which of your changes should be combined with his.
>>
>> I suggest Helge to rebase his change to my series. The below is some
>> detailed explanation:
>
>> It is almost orthogonal to my series, but patch 2 will conflict with
>> my series since it changes how the initial brk is calculated.
>>
>> Unfortunately I think patch 2 has a bug. Without my patch, do_brk()
>> assumes the heap is aligned with the host page size, but the patch
>> does not consider the case that the host and target page sizes are
>> different.
> I've included your patches #2 (bugfix) and #3 (cleanup) to my latest
> patch series and published it at
> https://github.com/hdeller/qemu-hppa/tree/brk-fixes-akihiko
>
> Maybe you and Joel could try it out?

I re-read the thread again. As it seems Joel already tried the latest
version from me? Sadly I can't test myself on ppc64le (static binary
needs klibc-PupSAGgtpafMlSLXOLgje1kXFo8.so in /usr/lib which I can't
install on a debian porterbox).

I still believe we need to track host and target brk page, but I'll give
your patch a try.

Helge
Re: [PATCH 0/5] linux-user: brk/mmap fixes
Posted by Helge Deller 9 months ago
On 7/31/23 19:43, Helge Deller wrote:
> On 7/31/23 18:47, Helge Deller wrote:
>> On 7/31/23 12:23, Akihiko Odaki wrote:
>>> On 2023/07/31 19:17, Joel Stanley wrote:
>>>> On Mon, 31 Jul 2023 at 09:31, Michael Tokarev <mjt@tls.msk.ru> wrote:
>>>>>
>>>>> 31.07.2023 11:03, Akihiko Odaki wrote:
>>>>>> linux-user was failing on M2 MacBook Air. Digging into the details, I found
>>>>>> several bugs in brk and mmap so here are fixes.
>>>>>
>>>>> There's another work in this area by Helge Deller, have you seen it?
>>>>> ("linux-user: Fix and optimize target memory layout", a v5 already).
>>>>
>>>> Applying this series fixes the qemu-arm running the static armhf
>>>> binary on my ppc64le host that I reported here[1].
>>> >> [1] https://lore.kernel.org/qemu-devel/CACPK8XeyqcEDyyL3Jw2WYWs_gGdtTCf2=Ly04CMgkshSMdj7RA@mail.gmail.com/
>>>>
>>>> Tested-by: Joel Stanley <joel@jms.id.au>
>>>
>>> Thanks for testing.
>>>
>>>>
>>>> The changes conflict with Helge's patches, so it would be good to work
>>>> out which of your changes should be combined with his.
>>>
>>> I suggest Helge to rebase his change to my series. The below is some
>>> detailed explanation:
>>
>>> It is almost orthogonal to my series, but patch 2 will conflict with
>>> my series since it changes how the initial brk is calculated.
>>>
>>> Unfortunately I think patch 2 has a bug. Without my patch, do_brk()
>>> assumes the heap is aligned with the host page size, but the patch
>>> does not consider the case that the host and target page sizes are
>>> different.
>> I've included your patches #2 (bugfix) and #3 (cleanup) to my latest
>> patch series and published it at
>> https://github.com/hdeller/qemu-hppa/tree/brk-fixes-akihiko
>>
>> Maybe you and Joel could try it out?
>
> I re-read the thread again. As it seems Joel already tried the latest
> version from me? Sadly I can't test myself on ppc64le (static binary
> needs klibc-PupSAGgtpafMlSLXOLgje1kXFo8.so in /usr/lib which I can't
> install on a debian porterbox).
>
> I still believe we need to track host and target brk page, but I'll give
> your patch a try.

As suggested, I've based my patches on top of yours and the tree can be
pulled from:
git pull https://github.com/hdeller/qemu-hppa/   brk-fixes-akihiko-2

My patches are neccessary to fix an arm-static testcase:
	/usr/bin/qemu-arm-static ./fstype

Let's try this patch series...

Helge
Re: [PATCH 0/5] linux-user: brk/mmap fixes
Posted by Joel Stanley 9 months ago
On Mon, 31 Jul 2023 at 18:24, Helge Deller <deller@gmx.de> wrote:

> > I re-read the thread again. As it seems Joel already tried the latest
> > version from me? Sadly I can't test myself on ppc64le (static binary
> > needs klibc-PupSAGgtpafMlSLXOLgje1kXFo8.so in /usr/lib which I can't
> > install on a debian porterbox).
> >
> > I still believe we need to track host and target brk page, but I'll give
> > your patch a try.
>
> As suggested, I've based my patches on top of yours and the tree can be
> pulled from:
> git pull https://github.com/hdeller/qemu-hppa/   brk-fixes-akihiko-2
>
> My patches are neccessary to fix an arm-static testcase:
>         /usr/bin/qemu-arm-static ./fstype
>
> Let's try this patch series...

The armhf static binary works with expected output.

The arm static binary causes qemu to segfault:

$ gdb -quiet --args ./build/qemu-arm -d guest_errors,page,strace ~/hello
Reading symbols from ./build/qemu-arm...
(gdb) r
Starting program: build/qemu-arm -d guest_errors,page,strace
/home/joel/hello
Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff762ece0 (LWP 118359)]
host mmap_min_addr=0x10000
pgb_find_hole: base @ 140420000 for 4294967296 bytes
pgb_static: base @ 140420000 for 4294967295 bytes
pgb_reserved_va: base @ 0x140420000 for 4294967296 bytes
Locating guest address space @ 0x140420000
page layout changed following mmap
start    end      size     prot
00010000-00090000 00080000 ---
00090000-0009b000 0000b000 ---
ffff0000-00000000 00010000 r-x
page layout changed following mmap
start    end      size     prot
00010000-00090000 00080000 r-x
00090000-0009b000 0000b000 ---
ffff0000-00000000 00010000 r-x
page layout changed following mmap
start    end      size     prot
00010000-00090000 00080000 r-x
00090000-000a0000 00010000 rw-
ffff0000-00000000 00010000 r-x
page layout changed following mmap
start    end      size     prot
00010000-00090000 00080000 r-x
00090000-000a0000 00010000 rw-
e0000000-e0810000 00810000 rw-
ffff0000-00000000 00010000 r-x
page layout changed following mmap
start    end      size     prot
00010000-00090000 00080000 r-x
00090000-000a0000 00010000 rw-
e0000000-e0010000 00010000 ---
e0010000-e0811000 00801000 rw-
ffff0000-00000000 00010000 r-x
guest_base  0x140420000
page layout changed following binary load
start    end      size     prot
00010000-00090000 00080000 r-x
00090000-000a0000 00010000 rw-
e0000000-e0010000 00010000 ---
e0010000-e0810000 00800000 rw-
e0810000-e0811000 00001000 r-x
ffff0000-00000000 00010000 r-x
start_brk   0x00000000
end_code    0x00084f7c
start_code  0x00010000
start_data  0x00095098
end_data    0x00098394
start_stack 0xe080f410
brk         0x0009b000
entry       0x00010418
argv_start  0xe080f414
env_start   0xe080f41c
auxv_start  0xe080f4a0
118357 brk(NULL) = 0x0009b000
118357 brk(0x0009b8fc) = 0x0009b000

Thread 1 "qemu-arm" received signal SIGSEGV, Segmentation fault.
0x00007fffeed9bb74 in code_gen_buffer ()
(gdb)
(gdb) bt
#0  0x00007fffeed9bb74 in code_gen_buffer ()
#1  0x0000000100169e3c in cpu_tb_exec (cpu=cpu@entry=0x1003d4aa0,
    itb=itb@entry=0x7fffeed9ba60 <code_gen_buffer+47512>,
tb_exit=tb_exit@entry=0x7fffffffe50c)
    at ../accel/tcg/cpu-exec.c:457
#2  0x000000010016a564 in cpu_loop_exec_tb (tb_exit=0x7fffffffe50c,
last_tb=<synthetic pointer>,
    pc=<optimised out>, tb=0x7fffeed9ba60 <code_gen_buffer+47512>,
cpu=<optimised out>)
    at ../accel/tcg/cpu-exec.c:919
#3  cpu_exec_loop (cpu=cpu@entry=0x1003d4aa0, sc=<optimised out>) at
../accel/tcg/cpu-exec.c:1040
#4  0x000000010016aa0c in cpu_exec_setjmp (cpu=cpu@entry=0x1003d4aa0,
sc=<optimised out>)
    at ../accel/tcg/cpu-exec.c:1057
#5  0x000000010016b0d0 in cpu_exec (cpu=0x1003d4aa0) at
../accel/tcg/cpu-exec.c:1083
#6  0x000000010004d780 in cpu_loop (env=0x1003d4fb0) at
../linux-user/arm/cpu_loop.c:323
#7  0x0000000100047534 in main (argc=<optimised out>,
argv=0x7ffffffff178, envp=<optimised out>)
    at ../linux-user/main.c:975

I tested 74a22a175c4340a01f6f860f72307093e3307681.
Re: [PATCH 0/5] linux-user: brk/mmap fixes
Posted by Helge Deller 9 months ago
On 8/1/23 06:49, Joel Stanley wrote:
> On Mon, 31 Jul 2023 at 18:24, Helge Deller <deller@gmx.de> wrote:
>> As suggested, I've based my patches on top of yours and the tree can be
>> pulled from:
>> git pull https://github.com/hdeller/qemu-hppa/   brk-fixes-akihiko-2
>>
>> My patches are neccessary to fix an arm-static testcase:
>>          /usr/bin/qemu-arm-static ./fstype
>>
>> Let's try this patch series...
>
> The armhf static binary works with expected output.

Good!

> The arm static binary causes qemu to segfault:

I can't reproduce here.
I tried it in an arm64 chroot which provided the cross-compiler and worked for me:

(arm64-chroot)root@p100:/# uname -a
Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 20:51:12 UTC 2023 aarch64 GNU/Linux
(arm64-chroot)root@p100:/# arm-linux-gnueabi-gcc-13 -o hello hello.c -static
(arm64-chroot)root@p100:/# file hello
hello: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, BuildID[sha1]=fa0f7cd6e1779fa8cd76c6e5d3123900ceefa952, for GNU/Linux 3.2.0, not stripped
(arm64-chroot)root@p100:/# ./hello
Hello, World!

Maybe you can send me your binary (and the needed klibc*so)?
Btw, I tested a whole bunch of platforms too, see below...

Helge

> $ gdb -quiet --args ./build/qemu-arm -d guest_errors,page,strace ~/hello
> Reading symbols from ./build/qemu-arm...
> (gdb) r
> Starting program: build/qemu-arm -d guest_errors,page,strace
> /home/joel/hello
> Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1".
> [New Thread 0x7ffff762ece0 (LWP 118359)]
> host mmap_min_addr=0x10000
> pgb_find_hole: base @ 140420000 for 4294967296 bytes
> pgb_static: base @ 140420000 for 4294967295 bytes
> pgb_reserved_va: base @ 0x140420000 for 4294967296 bytes
> Locating guest address space @ 0x140420000
> page layout changed following mmap
> start    end      size     prot
> 00010000-00090000 00080000 ---
> 00090000-0009b000 0000b000 ---
> ffff0000-00000000 00010000 r-x
> page layout changed following mmap
> start    end      size     prot
> 00010000-00090000 00080000 r-x
> 00090000-0009b000 0000b000 ---
> ffff0000-00000000 00010000 r-x
> page layout changed following mmap
> start    end      size     prot
> 00010000-00090000 00080000 r-x
> 00090000-000a0000 00010000 rw-
> ffff0000-00000000 00010000 r-x
> page layout changed following mmap
> start    end      size     prot
> 00010000-00090000 00080000 r-x
> 00090000-000a0000 00010000 rw-
> e0000000-e0810000 00810000 rw-
> ffff0000-00000000 00010000 r-x
> page layout changed following mmap
> start    end      size     prot
> 00010000-00090000 00080000 r-x
> 00090000-000a0000 00010000 rw-
> e0000000-e0010000 00010000 ---
> e0010000-e0811000 00801000 rw-
> ffff0000-00000000 00010000 r-x
> guest_base  0x140420000
> page layout changed following binary load
> start    end      size     prot
> 00010000-00090000 00080000 r-x
> 00090000-000a0000 00010000 rw-
> e0000000-e0010000 00010000 ---
> e0010000-e0810000 00800000 rw-
> e0810000-e0811000 00001000 r-x
> ffff0000-00000000 00010000 r-x
> start_brk   0x00000000
> end_code    0x00084f7c
> start_code  0x00010000
> start_data  0x00095098
> end_data    0x00098394
> start_stack 0xe080f410
> brk         0x0009b000
> entry       0x00010418
> argv_start  0xe080f414
> env_start   0xe080f41c
> auxv_start  0xe080f4a0
> 118357 brk(NULL) = 0x0009b000
> 118357 brk(0x0009b8fc) = 0x0009b000
>
> Thread 1 "qemu-arm" received signal SIGSEGV, Segmentation fault.
> 0x00007fffeed9bb74 in code_gen_buffer ()
> (gdb)
> (gdb) bt
> #0  0x00007fffeed9bb74 in code_gen_buffer ()
> #1  0x0000000100169e3c in cpu_tb_exec (cpu=cpu@entry=0x1003d4aa0,
>      itb=itb@entry=0x7fffeed9ba60 <code_gen_buffer+47512>,
> tb_exit=tb_exit@entry=0x7fffffffe50c)
>      at ../accel/tcg/cpu-exec.c:457
> #2  0x000000010016a564 in cpu_loop_exec_tb (tb_exit=0x7fffffffe50c,
> last_tb=<synthetic pointer>,
>      pc=<optimised out>, tb=0x7fffeed9ba60 <code_gen_buffer+47512>,
> cpu=<optimised out>)
>      at ../accel/tcg/cpu-exec.c:919
> #3  cpu_exec_loop (cpu=cpu@entry=0x1003d4aa0, sc=<optimised out>) at
> ../accel/tcg/cpu-exec.c:1040
> #4  0x000000010016aa0c in cpu_exec_setjmp (cpu=cpu@entry=0x1003d4aa0,
> sc=<optimised out>)
>      at ../accel/tcg/cpu-exec.c:1057
> #5  0x000000010016b0d0 in cpu_exec (cpu=0x1003d4aa0) at
> ../accel/tcg/cpu-exec.c:1083
> #6  0x000000010004d780 in cpu_loop (env=0x1003d4fb0) at
> ../linux-user/arm/cpu_loop.c:323
> #7  0x0000000100047534 in main (argc=<optimised out>,
> argv=0x7ffffffff178, envp=<optimised out>)
>      at ../linux-user/main.c:975
>
> I tested 74a22a175c4340a01f6f860f72307093e3307681.

Those I did tested sucessfully (static binary):

alpha-chroot:
Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 20:51:12 UTC 2023 alpha GNU/Linux
/hello: ELF 64-bit LSB executable, Alpha (unofficial), version 1 (SYSV), statically linked, BuildID[sha1]=5bf21139aa3937121e8843b062619de8e53d035a, for GNU/Linux 3.2.0, not stripped
Hello, World!

arm64-chroot:
Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 20:51:12 UTC 2023 aarch64 GNU/Linux
/hello: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=201827af1ffdef4fc2afa404047c6d1a41e4825e, for GNU/Linux 3.7.0, not stripped
Hello, World!

armel-chroot:
Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 20:51:12 UTC 2023 armv7l GNU/Linux
/hello: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, BuildID[sha1]=6e6a52f60037690052b2e54e750a56543ed9d7a0, for GNU/Linux 3.2.0, not stripped
Hello, World!

armhf-chroot:
Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 20:51:12 UTC 2023 armv7l GNU/Linux
/hello: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), statically linked, BuildID[sha1]=842df9fd0bf910f6a00c19d61435387efa591390, for GNU/Linux 3.2.0, not stripped
Hello, World!

hppa-chroot:
Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 20:51:12 UTC 2023 parisc GNU/Linux
/hello: ELF 32-bit MSB executable, PA-RISC, 1.1 version 1 (GNU/Linux), statically linked, BuildID[sha1]=03d4b299b31d30b5920e9fdcfccce071b77e4447, for GNU/Linux 3.2.0, not stripped
Hello, World!

m68k-chroot:
Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 20:51:12 UTC 2023 m68k GNU/Linux
/hello: ELF 32-bit MSB executable, Motorola m68k, 68020, version 1 (SYSV), statically linked, BuildID[sha1]=c01101b8ae6a6a0161a08b6ac24821b28daa5b73, for GNU/Linux 3.2.0, not stripped
Hello, World!

mips64el-chroot:
Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 20:51:12 UTC 2023 mips64 GNU/Linux
/hello: ELF 64-bit LSB executable, MIPS, MIPS64 rel2 version 1 (SYSV), statically linked, BuildID[sha1]=0c50fc29be7ef781cdfb4ec4c47b4e350cab218b, for GNU/Linux 3.2.0, not stripped
Hello, World!

mipsel-chroot:
Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 20:51:12 UTC 2023 mips GNU/Linux
/hello: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), statically linked, BuildID[sha1]=e0db11bbc59070f5fefb4355d73df76791e96c29, for GNU/Linux 3.2.0, not stripped
Hello, World!

powerpc-chroot:
Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 20:51:12 UTC 2023 ppc GNU/Linux
/hello: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, BuildID[sha1]=4fe85ef8ebd86eb383ccf4fd741ce224143da2b2, for GNU/Linux 3.2.0, not stripped
Hello, World!

ppc64-chroot:
Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 20:51:12 UTC 2023 ppc64 GNU/Linux
/hello: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, Power ELF V1 ABI, version 1 (GNU/Linux), statically linked, BuildID[sha1]=c3bb5c4d94b2096f70261bf0ab1f3fc93813df8f, for GNU/Linux 3.2.0, not stripped
Hello, World!

ppc64el-chroot:
Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 20:51:12 UTC 2023 ppc64le GNU/Linux
/hello: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, OpenPOWER ELF V2 ABI, version 1 (GNU/Linux), statically linked, BuildID[sha1]=645abb5dcd9075d826d539675258fa5f9c7bc777, for GNU/Linux 3.10.0, not stripped
Hello, World!

s390x-chroot:
Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 20:51:12 UTC 2023 s390x GNU/Linux
/hello: ELF 64-bit MSB executable, IBM S/390, version 1 (GNU/Linux), statically linked, BuildID[sha1]=f512d5ac759962ab66ae947d1308c8ceedef8fd3, for GNU/Linux 3.2.0, not stripped
Hello, World!

sh4-chroot:
Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 20:51:12 UTC 2023 sh4 GNU/Linux
/hello: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), statically linked, BuildID[sha1]=4cf38c7f67b5d7dc7a93c6ab513aaf0d2d21c4fc, for GNU/Linux 3.2.0, not stripped
Hello, World!

sparc64-chroot:
Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 20:51:12 UTC 2023 sparc64 GNU/Linux
/hello: ELF 64-bit MSB executable, SPARC V9, Sun UltraSPARC1 Extensions Required, relaxed memory ordering, version 1 (GNU/Linux), statically linked, BuildID[sha1]=36f02b1b3acc94f61dff6dc26205f82314c899e0, for GNU/Linux 3.2.0, not stripped
Hello, World!
Re: [PATCH 0/5] linux-user: brk/mmap fixes
Posted by Akihiko Odaki 9 months ago
On 2023/08/01 19:43, Helge Deller wrote:
> On 8/1/23 06:49, Joel Stanley wrote:
>> On Mon, 31 Jul 2023 at 18:24, Helge Deller <deller@gmx.de> wrote:
>>> As suggested, I've based my patches on top of yours and the tree can be
>>> pulled from:
>>> git pull https://github.com/hdeller/qemu-hppa/   brk-fixes-akihiko-2
>>>
>>> My patches are neccessary to fix an arm-static testcase:
>>>          /usr/bin/qemu-arm-static ./fstype
>>>
>>> Let's try this patch series...
>>
>> The armhf static binary works with expected output.
> 
> Good!
> 
>> The arm static binary causes qemu to segfault:
> 
> I can't reproduce here.
> I tried it in an arm64 chroot which provided the cross-compiler and 
> worked for me:
> 
> (arm64-chroot)root@p100:/# uname -a
> Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 
> 20:51:12 UTC 2023 aarch64 GNU/Linux
> (arm64-chroot)root@p100:/# arm-linux-gnueabi-gcc-13 -o hello hello.c 
> -static
> (arm64-chroot)root@p100:/# file hello
> hello: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), 
> statically linked, 
> BuildID[sha1]=fa0f7cd6e1779fa8cd76c6e5d3123900ceefa952, for GNU/Linux 
> 3.2.0, not stripped
> (arm64-chroot)root@p100:/# ./hello
> Hello, World!
> 
> Maybe you can send me your binary (and the needed klibc*so)?

Binaries will certainly help. I also suggest adding -trace target_mmap 
so that we can see what's passed to target_mmap().

I also sent a new version so please rebase to it and try again.
https://patchew.org/QEMU/20230802071754.14876-1-akihiko.odaki@daynix.com/

Helge, please rebase your series to the series, include only your 
patches in your series, and add the following to the cover letter:

Based-on: <20230802071754.14876-1-akihiko.odaki@daynix.com>
("[PATCH v2 0/6] linux-user: brk/mmap fixes")

> Btw, I tested a whole bunch of platforms too, see below...
> 
> Helge
> 
>> $ gdb -quiet --args ./build/qemu-arm -d guest_errors,page,strace ~/hello
>> Reading symbols from ./build/qemu-arm...
>> (gdb) r
>> Starting program: build/qemu-arm -d guest_errors,page,strace
>> /home/joel/hello
>> Using host libthread_db library 
>> "/lib/powerpc64le-linux-gnu/libthread_db.so.1".
>> [New Thread 0x7ffff762ece0 (LWP 118359)]
>> host mmap_min_addr=0x10000
>> pgb_find_hole: base @ 140420000 for 4294967296 bytes
>> pgb_static: base @ 140420000 for 4294967295 bytes
>> pgb_reserved_va: base @ 0x140420000 for 4294967296 bytes
>> Locating guest address space @ 0x140420000
>> page layout changed following mmap
>> start    end      size     prot
>> 00010000-00090000 00080000 ---
>> 00090000-0009b000 0000b000 ---
>> ffff0000-00000000 00010000 r-x
>> page layout changed following mmap
>> start    end      size     prot
>> 00010000-00090000 00080000 r-x
>> 00090000-0009b000 0000b000 ---
>> ffff0000-00000000 00010000 r-x
>> page layout changed following mmap
>> start    end      size     prot
>> 00010000-00090000 00080000 r-x
>> 00090000-000a0000 00010000 rw-
>> ffff0000-00000000 00010000 r-x
>> page layout changed following mmap
>> start    end      size     prot
>> 00010000-00090000 00080000 r-x
>> 00090000-000a0000 00010000 rw-
>> e0000000-e0810000 00810000 rw-
>> ffff0000-00000000 00010000 r-x
>> page layout changed following mmap
>> start    end      size     prot
>> 00010000-00090000 00080000 r-x
>> 00090000-000a0000 00010000 rw-
>> e0000000-e0010000 00010000 ---
>> e0010000-e0811000 00801000 rw-
>> ffff0000-00000000 00010000 r-x
>> guest_base  0x140420000
>> page layout changed following binary load
>> start    end      size     prot
>> 00010000-00090000 00080000 r-x
>> 00090000-000a0000 00010000 rw-
>> e0000000-e0010000 00010000 ---
>> e0010000-e0810000 00800000 rw-
>> e0810000-e0811000 00001000 r-x
>> ffff0000-00000000 00010000 r-x
>> start_brk   0x00000000
>> end_code    0x00084f7c
>> start_code  0x00010000
>> start_data  0x00095098
>> end_data    0x00098394
>> start_stack 0xe080f410
>> brk         0x0009b000
>> entry       0x00010418
>> argv_start  0xe080f414
>> env_start   0xe080f41c
>> auxv_start  0xe080f4a0
>> 118357 brk(NULL) = 0x0009b000
>> 118357 brk(0x0009b8fc) = 0x0009b000
>>
>> Thread 1 "qemu-arm" received signal SIGSEGV, Segmentation fault.
>> 0x00007fffeed9bb74 in code_gen_buffer ()
>> (gdb)
>> (gdb) bt
>> #0  0x00007fffeed9bb74 in code_gen_buffer ()
>> #1  0x0000000100169e3c in cpu_tb_exec (cpu=cpu@entry=0x1003d4aa0,
>>      itb=itb@entry=0x7fffeed9ba60 <code_gen_buffer+47512>,
>> tb_exit=tb_exit@entry=0x7fffffffe50c)
>>      at ../accel/tcg/cpu-exec.c:457
>> #2  0x000000010016a564 in cpu_loop_exec_tb (tb_exit=0x7fffffffe50c,
>> last_tb=<synthetic pointer>,
>>      pc=<optimised out>, tb=0x7fffeed9ba60 <code_gen_buffer+47512>,
>> cpu=<optimised out>)
>>      at ../accel/tcg/cpu-exec.c:919
>> #3  cpu_exec_loop (cpu=cpu@entry=0x1003d4aa0, sc=<optimised out>) at
>> ../accel/tcg/cpu-exec.c:1040
>> #4  0x000000010016aa0c in cpu_exec_setjmp (cpu=cpu@entry=0x1003d4aa0,
>> sc=<optimised out>)
>>      at ../accel/tcg/cpu-exec.c:1057
>> #5  0x000000010016b0d0 in cpu_exec (cpu=0x1003d4aa0) at
>> ../accel/tcg/cpu-exec.c:1083
>> #6  0x000000010004d780 in cpu_loop (env=0x1003d4fb0) at
>> ../linux-user/arm/cpu_loop.c:323
>> #7  0x0000000100047534 in main (argc=<optimised out>,
>> argv=0x7ffffffff178, envp=<optimised out>)
>>      at ../linux-user/main.c:975
>>
>> I tested 74a22a175c4340a01f6f860f72307093e3307681.
> 
> Those I did tested sucessfully (static binary):
> 
> alpha-chroot:
> Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 
> 20:51:12 UTC 2023 alpha GNU/Linux
> /hello: ELF 64-bit LSB executable, Alpha (unofficial), version 1 (SYSV), 
> statically linked, 
> BuildID[sha1]=5bf21139aa3937121e8843b062619de8e53d035a, for GNU/Linux 
> 3.2.0, not stripped
> Hello, World!
> 
> arm64-chroot:
> Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 
> 20:51:12 UTC 2023 aarch64 GNU/Linux
> /hello: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), 
> statically linked, 
> BuildID[sha1]=201827af1ffdef4fc2afa404047c6d1a41e4825e, for GNU/Linux 
> 3.7.0, not stripped
> Hello, World!
> 
> armel-chroot:
> Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 
> 20:51:12 UTC 2023 armv7l GNU/Linux
> /hello: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), 
> statically linked, 
> BuildID[sha1]=6e6a52f60037690052b2e54e750a56543ed9d7a0, for GNU/Linux 
> 3.2.0, not stripped
> Hello, World!
> 
> armhf-chroot:
> Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 
> 20:51:12 UTC 2023 armv7l GNU/Linux
> /hello: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), 
> statically linked, 
> BuildID[sha1]=842df9fd0bf910f6a00c19d61435387efa591390, for GNU/Linux 
> 3.2.0, not stripped
> Hello, World!
> 
> hppa-chroot:
> Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 
> 20:51:12 UTC 2023 parisc GNU/Linux
> /hello: ELF 32-bit MSB executable, PA-RISC, 1.1 version 1 (GNU/Linux), 
> statically linked, 
> BuildID[sha1]=03d4b299b31d30b5920e9fdcfccce071b77e4447, for GNU/Linux 
> 3.2.0, not stripped
> Hello, World!
> 
> m68k-chroot:
> Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 
> 20:51:12 UTC 2023 m68k GNU/Linux
> /hello: ELF 32-bit MSB executable, Motorola m68k, 68020, version 1 
> (SYSV), statically linked, 
> BuildID[sha1]=c01101b8ae6a6a0161a08b6ac24821b28daa5b73, for GNU/Linux 
> 3.2.0, not stripped
> Hello, World!
> 
> mips64el-chroot:
> Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 
> 20:51:12 UTC 2023 mips64 GNU/Linux
> /hello: ELF 64-bit LSB executable, MIPS, MIPS64 rel2 version 1 (SYSV), 
> statically linked, 
> BuildID[sha1]=0c50fc29be7ef781cdfb4ec4c47b4e350cab218b, for GNU/Linux 
> 3.2.0, not stripped
> Hello, World!
> 
> mipsel-chroot:
> Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 
> 20:51:12 UTC 2023 mips GNU/Linux
> /hello: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), 
> statically linked, 
> BuildID[sha1]=e0db11bbc59070f5fefb4355d73df76791e96c29, for GNU/Linux 
> 3.2.0, not stripped
> Hello, World!
> 
> powerpc-chroot:
> Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 
> 20:51:12 UTC 2023 ppc GNU/Linux
> /hello: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 
> (SYSV), statically linked, 
> BuildID[sha1]=4fe85ef8ebd86eb383ccf4fd741ce224143da2b2, for GNU/Linux 
> 3.2.0, not stripped
> Hello, World!
> 
> ppc64-chroot:
> Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 
> 20:51:12 UTC 2023 ppc64 GNU/Linux
> /hello: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, Power 
> ELF V1 ABI, version 1 (GNU/Linux), statically linked, 
> BuildID[sha1]=c3bb5c4d94b2096f70261bf0ab1f3fc93813df8f, for GNU/Linux 
> 3.2.0, not stripped
> Hello, World!
> 
> ppc64el-chroot:
> Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 
> 20:51:12 UTC 2023 ppc64le GNU/Linux
> /hello: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, 
> OpenPOWER ELF V2 ABI, version 1 (GNU/Linux), statically linked, 
> BuildID[sha1]=645abb5dcd9075d826d539675258fa5f9c7bc777, for GNU/Linux 
> 3.10.0, not stripped
> Hello, World!
> 
> s390x-chroot:
> Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 
> 20:51:12 UTC 2023 s390x GNU/Linux
> /hello: ELF 64-bit MSB executable, IBM S/390, version 1 (GNU/Linux), 
> statically linked, 
> BuildID[sha1]=f512d5ac759962ab66ae947d1308c8ceedef8fd3, for GNU/Linux 
> 3.2.0, not stripped
> Hello, World!
> 
> sh4-chroot:
> Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 
> 20:51:12 UTC 2023 sh4 GNU/Linux
> /hello: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), 
> statically linked, 
> BuildID[sha1]=4cf38c7f67b5d7dc7a93c6ab513aaf0d2d21c4fc, for GNU/Linux 
> 3.2.0, not stripped
> Hello, World!
> 
> sparc64-chroot:
> Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 
> 20:51:12 UTC 2023 sparc64 GNU/Linux
> /hello: ELF 64-bit MSB executable, SPARC V9, Sun UltraSPARC1 Extensions 
> Required, relaxed memory ordering, version 1 (GNU/Linux), statically 
> linked, BuildID[sha1]=36f02b1b3acc94f61dff6dc26205f82314c899e0, for 
> GNU/Linux 3.2.0, not stripped
> Hello, World!

Re: [PATCH 0/5] linux-user: brk/mmap fixes
Posted by Helge Deller 9 months ago
On 8/2/23 09:26, Akihiko Odaki wrote:
> On 2023/08/01 19:43, Helge Deller wrote:
>> On 8/1/23 06:49, Joel Stanley wrote:
>>> On Mon, 31 Jul 2023 at 18:24, Helge Deller <deller@gmx.de> wrote:
>>>> As suggested, I've based my patches on top of yours and the tree can be
>>>> pulled from:
>>>> git pull https://github.com/hdeller/qemu-hppa/   brk-fixes-akihiko-2
>>>>
>>>> My patches are neccessary to fix an arm-static testcase:
>>>>          /usr/bin/qemu-arm-static ./fstype
>>>>
>>>> Let's try this patch series...
>>>
>>> The armhf static binary works with expected output.
>>
>> Good!
>>
>>> The arm static binary causes qemu to segfault:
>>
>> I can't reproduce here.
>> I tried it in an arm64 chroot which provided the cross-compiler and worked for me:
>>
>> (arm64-chroot)root@p100:/# uname -a
>> Linux p100 6.4.6-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jul 24 20:51:12 UTC 2023 aarch64 GNU/Linux
>> (arm64-chroot)root@p100:/# arm-linux-gnueabi-gcc-13 -o hello hello.c -static
>> (arm64-chroot)root@p100:/# file hello
>> hello: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, BuildID[sha1]=fa0f7cd6e1779fa8cd76c6e5d3123900ceefa952, for GNU/Linux 3.2.0, not stripped
>> (arm64-chroot)root@p100:/# ./hello
>> Hello, World!
>>
>> Maybe you can send me your binary (and the needed klibc*so)?
>
> Binaries will certainly help. I also suggest adding -trace target_mmap so that we can see what's passed to target_mmap().
>
> I also sent a new version so please rebase to it and try again.
> https://patchew.org/QEMU/20230802071754.14876-1-akihiko.odaki@daynix.com/
>
> Helge, please rebase your series to the series, include only your patches in your series, and add the following to the cover letter:

Will do. I sent them out bundled for convinience.

Helge

> Based-on: <20230802071754.14876-1-akihiko.odaki@daynix.com>
> ("[PATCH v2 0/6] linux-user: brk/mmap fixes")