See also
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040981#84
(this and next messages at least)
for some additional background and analysis.
There's also
https://github.com/hdeller/qemu-hppa/commits/upx-fix
mentioned in subsequent message there.
/mjt
14.07.2023 22:43, Michael Tokarev wrote:
..
./arm-linux-user/qemu-arm /usr/lib/klibc/bin/fstype
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
Note: the segfault happens before qemu tries to run the program,
apparently when it is doing the file sections pr
Le 18/01/2020 à 00:02, Richard Henderson a écrit :
> With bad luck, we can wind up with no space at all for brk,
> which will generally cause the guest malloc to fail.
>
> This bad luck is easier to come by with ET_DYN (PIE) binaries,
> where either the stack or the interpreter (ld.so) gets placed
Warner Losh writes:
> On Fri, Jan 17, 2020 at 4:03 PM Richard Henderson <
> richard.hender...@linaro.org> wrote:
>
>> With bad luck, we can wind up with no space at all for brk,
>> which will generally cause the guest malloc to fail.
>>
> ...
>
>> The choice of 16MB is somewhat arbitrary. It's
Richard Henderson writes:
> With bad luck, we can wind up with no space at all for brk,
> which will generally cause the guest malloc to fail.
>
> This bad luck is easier to come by with ET_DYN (PIE) binaries,
> where either the stack or the interpreter (ld.so) gets placed
> immediately after t
On Fri, Jan 17, 2020 at 4:03 PM Richard Henderson <
richard.hender...@linaro.org> wrote:
> With bad luck, we can wind up with no space at all for brk,
> which will generally cause the guest malloc to fail.
>
...
> The choice of 16MB is somewhat arbitrary. It's enough for libc
> to get going, but
With bad luck, we can wind up with no space at all for brk,
which will generally cause the guest malloc to fail.
This bad luck is easier to come by with ET_DYN (PIE) binaries,
where either the stack or the interpreter (ld.so) gets placed
immediately after the main executable.
But there's nothing
