On 7/17/23 22:21, Michael Tokarev wrote:
17.07.2023 22:58, Helge Deller wrote:
This patch seems to work. Tested with qemu-arm and qemu-amd64.
Wow!
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index a26200d9f3..b583018591 100644
--- a/linux-user/elfload.c
+++
17.07.2023 22:58, Helge Deller wrote:
This patch seems to work. Tested with qemu-arm and qemu-amd64.
Wow!
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index a26200d9f3..b583018591 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -3615,6 +3631,13 @@ int
This patch seems to work. Tested with qemu-arm and qemu-amd64.
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index a26200d9f3..b583018591 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -3615,6 +3631,13 @@ int load_elf_binary(struct linux_binprm *bprm, struct
Without the patch this is the memory layout:
startend size prot
0001-00011000 1000 r-x
00011000-0002 f000 ---
0002-00021000 1000 rw-
4000-40001000 1000 ---
40001000-40801000 0080 rwx
40801000-40802000 1000 r-x
The difference between armhf and
This patch (hack) fixes the crash on armhf.
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index a26200d9f3..2efa981061 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -3674,7 +3685,7 @@ int load_elf_binary(struct linux_binprm *bprm, struct
image_info *info)
* The
17.07.2023 15:55, Helge Deller wrote:
Hello,
Could someone please try the 3 qemu patches (and one revert) which I pushed to my
"upx-fix"
branch with this binary?
It's based on top of qemu git master:
https://github.com/hdeller/qemu-hppa/commits/upx-fix
You can pull from:
git pull
Hello,
Could someone please try the 3 qemu patches (and one revert) which I pushed to my
"upx-fix"
branch with this binary?
It's based on top of qemu git master:
https://github.com/hdeller/qemu-hppa/commits/upx-fix
You can pull from:
git pull https://github.com/hdeller/qemu-hppa.git upx-fix
On Fri, 2023-07-14 at 22:08 +, Thorsten Glaser wrote:
> Michael Tokarev dixit:
>
> > >
> > > From the comment, it reserves 16 MiB after the main executable.
> > >
> > > In klibc/armhf, however, the main executable starts around
> > > 0x0001 whereas the interpreter starts after that,
Michael Tokarev dixit:
>>
>> From the comment, it reserves 16 MiB after the main executable.
>>
>> In klibc/armhf, however, the main executable starts around
>> 0x0001 whereas the interpreter starts after that, around
>> 0x0038…
>
> Aren't it happens on all architectures, not just armhf?
Control: forwarded -1
https://lists.nongnu.org/archive/html/qemu-devel/2023-07/msg03138.html
14.07.2023 23:07, Thorsten Glaser wrote:
Michael Tokarev dixit:
commit 6fd5944980f4ccee728ce34bdaffc117db50b34d
From the comment, it reserves 16 MiB after the main executable.
In klibc/armhf,
Michael Tokarev dixit:
> commit 6fd5944980f4ccee728ce34bdaffc117db50b34d
From the comment, it reserves 16 MiB after the main executable.
In klibc/armhf, however, the main executable starts around
0x0001 whereas the interpreter starts after that, around
0x0038…
Perhaps the fix here
14.07.2023 21:34, Thorsten Glaser wrote:
..
And, indeed, the combination of klibc-sKNr1Fw-Rh9G1FYpGCXRnrwmP2A.so
and fstype from 2.0.4-2 (jessie) also fails, so you have something
that can reliably be used in bisect tests I think.
Ok, this works. The bisection points to this commit between
Ben Hutchings dixit:
>7.2. This introduced regressions for shared-library executables for
I did notice the following:
amd64:
/lib/klibc-YUkGbOClhnaZRUUd4cUed0X2XZI.so: file format elf64-x86-64
/lib/klibc-YUkGbOClhnaZRUUd4cUed0X2XZI.so
architecture: i386:x86-64, flags 0x0102:
EXEC_P,
On 7/14/23 01:56, Thorsten Glaser wrote:
Dixi quod…
My guess here is that it’s, as usual, the fault of qemu-user,
Strong evidence for that: doesn’t look like it even executes
one bit of klibc code:
$ qemu-arm-static -d cpu ./fstype --help
qemu: uncaught target signal 11 (Segmentation fault)
Dixi quod…
>My guess here is that it’s, as usual, the fault of qemu-user,
Strong evidence for that: doesn’t look like it even executes
one bit of klibc code:
$ qemu-arm-static -d cpu ./fstype --help
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core
Hi Helge,
>Can you check if this patch fixes the problem:
>https://patchew.org/QEMU/mvmpm55qnno@suse.de/
>(linux-user: make sure brk(0) returns a page-aligned value, from Andreas
>Schwab)
I doubt it, klibc malloc uses mmap(2) normally.
(And given I tested it on a bullseye system, the
Dixi quod…
>My guess here is that it’s, as usual, the fault of qemu-user,
>which has multiple outstanding emulation bugs, some of which
>affecting klibc-built binaries especially, though this, since
>a statically linked mksh works, is probably an issue with how
>qemu-user handles .interp *shrug*
17 matches
Mail list logo
