[PATCH 1/2] Fix for Haiku

[PATCH 1/2] Fix for Haiku

[Richard Zak]

[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]

For Haiku: turn off TPM, disable mips & xtensa emulators as they won't
compile on Haiku, use Haiku's capstone. I'm resending this as I previously
sent to the wrong address. This should resolve the memory issue with "make
vm-build-haiku.x86_64"

Signed-off-by: Richard Zak <richard.j.zak@gmail.com>
---
 configure | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index e799d908a3..a965c6c72e 100755
--- a/configure
+++ b/configure
@@ -358,6 +358,7 @@ oss_lib=""
 bsd="no"
 linux="no"
 solaris="no"
+haiku="no"
 profiler="no"
 cocoa="auto"
 softmmu="yes"
@@ -769,7 +770,10 @@ SunOS)
 ;;
 Haiku)
   haiku="yes"
-  QEMU_CFLAGS="-DB_USE_POSITIVE_POSIX_ERRORS -D_BSD_SOURCE $QEMU_CFLAGS"
+  tpm="no"
+  capstone="system"
+  target_list_exclude="mips-softmmu mipsel-softmmu mips64-softmmu
mips64el-softmmu xtensa-softmmu xtensaeb-softmmu"
+  QEMU_CFLAGS="-DB_USE_POSITIVE_POSIX_ERRORS -D_BSD_SOURCE -I`finddir
B_SYSTEM_HEADERS_DIRECTORY`/capstone $QEMU_CFLAGS"
 ;;
 Linux)
   audio_drv_list="try-pa oss"
-- 
2.25.1


-- 
Regards,

Richard J. Zak
Professional Genius
PGP Key: https://keybase.io/rjzak/key.asc

[-- Attachment #2: Type: text/html, Size: 1823 bytes --]

Re: [PATCH 1/2] Fix for Haiku

[Peter Maydell]

On Sat, 3 Jul 2021 at 22:10, Richard Zak <richard.j.zak@gmail.com> wrote:
>
> For Haiku: turn off TPM, disable mips & xtensa emulators as they won't compile on Haiku, use Haiku's capstone. I'm resending this as I previously sent to the wrong address. This should resolve the memory issue with "make vm-build-haiku.x86_64"


So why don't the mips and xtensa emulators compile on Haiku?
What goes wrong ?

> Signed-off-by: Richard Zak <richard.j.zak@gmail.com>
> ---
>  configure | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index e799d908a3..a965c6c72e 100755
> --- a/configure
> +++ b/configure
> @@ -358,6 +358,7 @@ oss_lib=""
>  bsd="no"
>  linux="no"
>  solaris="no"
> +haiku="no"
>  profiler="no"
>  cocoa="auto"
>  softmmu="yes"
> @@ -769,7 +770,10 @@ SunOS)
>  ;;
>  Haiku)
>    haiku="yes"
> -  QEMU_CFLAGS="-DB_USE_POSITIVE_POSIX_ERRORS -D_BSD_SOURCE $QEMU_CFLAGS"
> +  tpm="no"

Why do we need to disable tpm?

> +  capstone="system"
> +  target_list_exclude="mips-softmmu mipsel-softmmu mips64-softmmu mips64el-softmmu xtensa-softmmu xtensaeb-softmmu"
> +  QEMU_CFLAGS="-DB_USE_POSITIVE_POSIX_ERRORS -D_BSD_SOURCE -I`finddir B_SYSTEM_HEADERS_DIRECTORY`/capstone $QEMU_CFLAGS"

It seems a bit odd that we have to manually put the capstone headers
on the include path. meson.build runs pkg-config to ask where the system
capstone headers are: does Haiku return the wrong value there?

thanks
-- PMM

Re: [PATCH 1/2] Fix for Haiku

[Richard Zak]

[-- Attachment #1: Type: text/plain, Size: 3519 bytes --]

For MIPS (all sub-targets, 64-bit and EL) & xtensa(eb), the compiler
complains about running out of memory. Best I can see, that's not what
actually happens, but that's the error message. I was going to investigate
this later, but this was the error which was causing the test with the
Haiku VM with that corresponding make target. My desktop & laptop have 64
GB, and I'm pretty sure it didn't get to that point.

/boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/8.3.0/../../../../x86_64-unknown-haiku/bin/ld:
error:
libqemu-mips-softmmu.fa.p/target_mips_tcg_sysemu_mips-semi.c.o(.rodata) is
too large (0xffff405a bytes)
/boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/8.3.0/../../../../x86_64-unknown-haiku/bin/ld:
final link failed: memory exhausted
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
Makefile:158: recipe for target 'run-ninja' failed
make: *** [run-ninja] Error 1

/boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/8.3.0/../../../../x86_64-unknown-haiku/bin/ld:
final link failed: memory exhausted
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
Makefile:158: recipe for target 'run-ninja' failed
make: *** [run-ninja] Error 1

TPM is disabled as it's not supported in Haiku. Using that "finddir"
command for capstone was done that way in Haiku's build recipe, so I copied
it into the configure script. A quick test shows that pkg-config does find
it properly, so I'll remove the "finddir" command and test again.

TPM and "finddir" command in Haiku's recipe for qemu:
https://github.com/haikuports/haikuports/blob/master/app-emulation/qemu/qemu-6.0.0.recipe

În sâm., 3 iul. 2021 la 17:40, Peter Maydell <peter.maydell@linaro.org> a
scris:

> On Sat, 3 Jul 2021 at 22:10, Richard Zak <richard.j.zak@gmail.com> wrote:
> >
> > For Haiku: turn off TPM, disable mips & xtensa emulators as they won't
> compile on Haiku, use Haiku's capstone. I'm resending this as I previously
> sent to the wrong address. This should resolve the memory issue with "make
> vm-build-haiku.x86_64"
>
>
> So why don't the mips and xtensa emulators compile on Haiku?
> What goes wrong ?
>
> > Signed-off-by: Richard Zak <richard.j.zak@gmail.com>
> > ---
> >  configure | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/configure b/configure
> > index e799d908a3..a965c6c72e 100755
> > --- a/configure
> > +++ b/configure
> > @@ -358,6 +358,7 @@ oss_lib=""
> >  bsd="no"
> >  linux="no"
> >  solaris="no"
> > +haiku="no"
> >  profiler="no"
> >  cocoa="auto"
> >  softmmu="yes"
> > @@ -769,7 +770,10 @@ SunOS)
> >  ;;
> >  Haiku)
> >    haiku="yes"
> > -  QEMU_CFLAGS="-DB_USE_POSITIVE_POSIX_ERRORS -D_BSD_SOURCE $QEMU_CFLAGS"
> > +  tpm="no"
>
> Why do we need to disable tpm?
>
> > +  capstone="system"
> > +  target_list_exclude="mips-softmmu mipsel-softmmu mips64-softmmu
> mips64el-softmmu xtensa-softmmu xtensaeb-softmmu"
> > +  QEMU_CFLAGS="-DB_USE_POSITIVE_POSIX_ERRORS -D_BSD_SOURCE -I`finddir
> B_SYSTEM_HEADERS_DIRECTORY`/capstone $QEMU_CFLAGS"
>
> It seems a bit odd that we have to manually put the capstone headers
> on the include path. meson.build runs pkg-config to ask where the system
> capstone headers are: does Haiku return the wrong value there?
>
> thanks
> -- PMM
>


-- 
Regards,

Richard J. Zak
Professional Genius
PGP Key: https://keybase.io/rjzak/key.asc

[-- Attachment #2: Type: text/html, Size: 4795 bytes --]

Re: [PATCH 1/2] Fix for Haiku

[Thomas Huth]

On 03/07/2021 23.10, Richard Zak wrote:
> For Haiku: turn off TPM, disable mips & xtensa emulators as they won't 
> compile on Haiku, use Haiku's capstone. I'm resending this as I previously 
> sent to the wrong address. This should resolve the memory issue with "make 
> vm-build-haiku.x86_64"
> 
> Signed-off-by: Richard Zak <richard.j.zak@gmail.com 
> <mailto:richard.j.zak@gmail.com>>
> ---
>   configure | 6 +++++-
>   1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index e799d908a3..a965c6c72e 100755
> --- a/configure
> +++ b/configure
> @@ -358,6 +358,7 @@ oss_lib=""
>   bsd="no"
>   linux="no"
>   solaris="no"
> +haiku="no"
>   profiler="no"
>   cocoa="auto"
>   softmmu="yes"
> @@ -769,7 +770,10 @@ SunOS)
>   ;;
>   Haiku)
>     haiku="yes"
> -  QEMU_CFLAGS="-DB_USE_POSITIVE_POSIX_ERRORS -D_BSD_SOURCE $QEMU_CFLAGS"
> +  tpm="no"

Why is tpm support not auto-detected?

> +  capstone="system"
> +  target_list_exclude="mips-softmmu mipsel-softmmu mips64-softmmu 
> mips64el-softmmu xtensa-softmmu xtensaeb-softmmu"

I think it's rather a bad idea to set target_list_exclude here since this 
will prevent that the users can use their own "--target-list" and 
"--target-list-exclude" switches for the configure script. But maybe you 
could add some logic later that checks whether the user set a target list, 
and if that's not the case then tweak the target_list_exclude accordingly.

> +  QEMU_CFLAGS="-DB_USE_POSITIVE_POSIX_ERRORS -D_BSD_SOURCE -I`finddir 
> B_SYSTEM_HEADERS_DIRECTORY`/capstone $QEMU_CFLAGS"
>   ;;
>   Linux)
>     audio_drv_list="try-pa oss"
> -- 
> 2.25.1

  Thomas

Re: [PATCH 1/2] Fix for Haiku

[Philippe Mathieu-Daudé]

On 7/4/21 12:06 AM, Richard Zak wrote:
> For MIPS (all sub-targets, 64-bit and EL) & xtensa(eb), the compiler
> complains about running out of memory. Best I can see, that's not what
> actually happens, but that's the error message. I was going to
> investigate this later, but this was the error which was causing the
> test with the Haiku VM with that corresponding make target. My desktop &
> laptop have 64 GB, and I'm pretty sure it didn't get to that point.
> 
> /boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/8.3.0/../../../../x86_64-unknown-haiku/bin/ld:
> error:
> libqemu-mips-softmmu.fa.p/target_mips_tcg_sysemu_mips-semi.c.o(.rodata)
> is too large (0xffff405a bytes)

This comes the following array from commit 2c44b19c199:

+/* Errno values taken from asm-mips/errno.h */
+static uint16_t host_to_mips_errno[] = {
+    [ENAMETOOLONG] = 78,
+#ifdef EOVERFLOW
+    [EOVERFLOW]    = 79,
+#endif
+#ifdef ELOOP
+    [ELOOP]        = 90,
+#endif
+};

See how Haiku handles POSIX errno:

https://github.com/haiku/haiku/blob/master/headers/os/support/Errors.h

#define B_GENERAL_ERROR_BASE   INT_MIN

#define B_POSIX_ERROR_BASE     (B_GENERAL_ERROR_BASE + 0x7000)

#define B_POSIX_ENOMEM  B_TO_POSIX_ERROR(B_POSIX_ERROR_BASE + 0)
#define E2BIG           B_TO_POSIX_ERROR(B_POSIX_ERROR_BASE + 1)
#define ECHILD          B_TO_POSIX_ERROR(B_POSIX_ERROR_BASE + 2)
...

Re: [PATCH 1/2] Fix for Haiku

[Philippe Mathieu-Daudé]

On 7/4/21 11:03 AM, Philippe Mathieu-Daudé wrote:
> On 7/4/21 12:06 AM, Richard Zak wrote:
>> For MIPS (all sub-targets, 64-bit and EL) & xtensa(eb), the compiler
>> complains about running out of memory. Best I can see, that's not what
>> actually happens, but that's the error message. I was going to
>> investigate this later, but this was the error which was causing the
>> test with the Haiku VM with that corresponding make target. My desktop &
>> laptop have 64 GB, and I'm pretty sure it didn't get to that point.
>>
>>
/boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/8.3.0/../../../../x86_64-unknown-haiku/bin/ld:
>> final link failed: memory exhausted

> See how Haiku handles POSIX errno:
> 
> https://github.com/haiku/haiku/blob/master/headers/os/support/Errors.h
> 
> #define B_GENERAL_ERROR_BASE   INT_MIN
> 
> #define B_POSIX_ERROR_BASE     (B_GENERAL_ERROR_BASE + 0x7000)
> 
> #define B_POSIX_ENOMEM  B_TO_POSIX_ERROR(B_POSIX_ERROR_BASE + 0)
> #define E2BIG           B_TO_POSIX_ERROR(B_POSIX_ERROR_BASE + 1)
> #define ECHILD          B_TO_POSIX_ERROR(B_POSIX_ERROR_BASE + 2)
> ...
> 

Same problem with Xtensa:

static uint32_t errno_h2g(int host_errno)
{
    static const uint32_t guest_errno[] = {
        [EPERM]         = TARGET_EPERM,
        [ENOENT]        = TARGET_ENOENT,
        [ESRCH]         = TARGET_ESRCH,
        [EINTR]         = TARGET_EINTR,
        [EIO]           = TARGET_EIO,
        [ENXIO]         = TARGET_ENXIO,
        [E2BIG]         = TARGET_E2BIG,
        [ENOEXEC]       = TARGET_ENOEXEC,
...

Re: [PATCH 1/2] Fix for Haiku

[Philippe Mathieu-Daudé]

On 7/4/21 11:27 AM, Philippe Mathieu-Daudé wrote:
> On 7/4/21 11:03 AM, Philippe Mathieu-Daudé wrote:
>> On 7/4/21 12:06 AM, Richard Zak wrote:
>>> For MIPS (all sub-targets, 64-bit and EL) & xtensa(eb), the compiler
>>> complains about running out of memory. Best I can see, that's not what
>>> actually happens, but that's the error message. I was going to
>>> investigate this later, but this was the error which was causing the
>>> test with the Haiku VM with that corresponding make target. My desktop &
>>> laptop have 64 GB, and I'm pretty sure it didn't get to that point.
>>>
>>>
> /boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/8.3.0/../../../../x86_64-unknown-haiku/bin/ld:
>>> final link failed: memory exhausted
> 
>> See how Haiku handles POSIX errno:
>>
>> https://github.com/haiku/haiku/blob/master/headers/os/support/Errors.h
>>
>> #define B_GENERAL_ERROR_BASE   INT_MIN
>>
>> #define B_POSIX_ERROR_BASE     (B_GENERAL_ERROR_BASE + 0x7000)
>>
>> #define B_POSIX_ENOMEM  B_TO_POSIX_ERROR(B_POSIX_ERROR_BASE + 0)
>> #define E2BIG           B_TO_POSIX_ERROR(B_POSIX_ERROR_BASE + 1)
>> #define ECHILD          B_TO_POSIX_ERROR(B_POSIX_ERROR_BASE + 2)
>> ...
>>
> 
> Same problem with Xtensa:
> 
> static uint32_t errno_h2g(int host_errno)
> {
>     static const uint32_t guest_errno[] = {
>         [EPERM]         = TARGET_EPERM,
>         [ENOENT]        = TARGET_ENOENT,
>         [ESRCH]         = TARGET_ESRCH,
>         [EINTR]         = TARGET_EINTR,
>         [EIO]           = TARGET_EIO,
>         [ENXIO]         = TARGET_ENXIO,
>         [E2BIG]         = TARGET_E2BIG,
>         [ENOEXEC]       = TARGET_ENOEXEC,
> ...

Annoyingly enough this is also how linux-user/syscall.c does
(thinking about code re-use):

/*
 * This list is the union of errno values overridden in asm-<arch>/errno.h
 * minus the errnos that are not actually generic to all archs.
 */
static uint16_t host_to_target_errno_table[ERRNO_TABLE_SIZE] = {
    [EAGAIN]		= TARGET_EAGAIN,
    [EIDRM]		= TARGET_EIDRM,
    [ECHRNG]		= TARGET_ECHRNG,
    [EL2NSYNC]		= TARGET_EL2NSYNC,
    [EL3HLT]		= TARGET_EL3HLT,
    [EL3RST]		= TARGET_EL3RST,
...

Re: [PATCH 1/2] Fix for Haiku

[Richard Zak]

[-- Attachment #1: Type: text/plain, Size: 3072 bytes --]

Exactly. One of the developers on the Haiku forum shared with me the patch
that Haiku uses for qemu, and it has a few lines concerning error codes.
I'll look into this.
https://github.com/haikuports/haikuports/blob/14c2cab5428145b93232cb69683a67bbe68a9f06/app-emulation/qemu/patches/qemu-3.1.1.1.patchset

This is a stopper for the configure script changes? I was thinking that
smaller changes would be best to keep the review more manageable. I'm also
still new around here :)

În dum., 4 iul. 2021 la 05:30, Philippe Mathieu-Daudé <f4bug@amsat.org> a
scris:

> On 7/4/21 11:27 AM, Philippe Mathieu-Daudé wrote:
> > On 7/4/21 11:03 AM, Philippe Mathieu-Daudé wrote:
> >> On 7/4/21 12:06 AM, Richard Zak wrote:
> >>> For MIPS (all sub-targets, 64-bit and EL) & xtensa(eb), the compiler
> >>> complains about running out of memory. Best I can see, that's not what
> >>> actually happens, but that's the error message. I was going to
> >>> investigate this later, but this was the error which was causing the
> >>> test with the Haiku VM with that corresponding make target. My desktop
> &
> >>> laptop have 64 GB, and I'm pretty sure it didn't get to that point.
> >>>
> >>>
> >
> /boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/8.3.0/../../../../x86_64-unknown-haiku/bin/ld:
> >>> final link failed: memory exhausted
> >
> >> See how Haiku handles POSIX errno:
> >>
> >> https://github.com/haiku/haiku/blob/master/headers/os/support/Errors.h
> >>
> >> #define B_GENERAL_ERROR_BASE   INT_MIN
> >>
> >> #define B_POSIX_ERROR_BASE     (B_GENERAL_ERROR_BASE + 0x7000)
> >>
> >> #define B_POSIX_ENOMEM  B_TO_POSIX_ERROR(B_POSIX_ERROR_BASE + 0)
> >> #define E2BIG           B_TO_POSIX_ERROR(B_POSIX_ERROR_BASE + 1)
> >> #define ECHILD          B_TO_POSIX_ERROR(B_POSIX_ERROR_BASE + 2)
> >> ...
> >>
> >
> > Same problem with Xtensa:
> >
> > static uint32_t errno_h2g(int host_errno)
> > {
> >     static const uint32_t guest_errno[] = {
> >         [EPERM]         = TARGET_EPERM,
> >         [ENOENT]        = TARGET_ENOENT,
> >         [ESRCH]         = TARGET_ESRCH,
> >         [EINTR]         = TARGET_EINTR,
> >         [EIO]           = TARGET_EIO,
> >         [ENXIO]         = TARGET_ENXIO,
> >         [E2BIG]         = TARGET_E2BIG,
> >         [ENOEXEC]       = TARGET_ENOEXEC,
> > ...
>
> Annoyingly enough this is also how linux-user/syscall.c does
> (thinking about code re-use):
>
> /*
>  * This list is the union of errno values overridden in asm-<arch>/errno.h
>  * minus the errnos that are not actually generic to all archs.
>  */
> static uint16_t host_to_target_errno_table[ERRNO_TABLE_SIZE] = {
>     [EAGAIN]            = TARGET_EAGAIN,
>     [EIDRM]             = TARGET_EIDRM,
>     [ECHRNG]            = TARGET_ECHRNG,
>     [EL2NSYNC]          = TARGET_EL2NSYNC,
>     [EL3HLT]            = TARGET_EL3HLT,
>     [EL3RST]            = TARGET_EL3RST,
> ...
>


-- 
Regards,

Richard J. Zak
Professional Genius
PGP Key: https://keybase.io/rjzak/key.asc

[-- Attachment #2: Type: text/html, Size: 4407 bytes --]

Re: [PATCH 1/2] Fix for Haiku

[Thomas Huth]

Meta comment: Please avoid
ƃuıʇsod uʍop ǝpısdn
... it makes threads much harder to read.

On 04/07/2021 16.20, Richard Zak wrote:
> Exactly. One of the developers on the Haiku forum shared with me the patch 
> that Haiku uses for qemu, and it has a few lines concerning error codes. 
> I'll look into this.
> https://github.com/haikuports/haikuports/blob/14c2cab5428145b93232cb69683a67bbe68a9f06/app-emulation/qemu/patches/qemu-3.1.1.1.patchset 

So something like the change in target/xtensa/xtensa-semi.c is the right way 
to go - using a switch-case statement looks like the right fix instead of 
disabling the targets in the configure script.

> This is a stopper for the configure script changes?

Well, if anyhow possible, we should avoid hacks like disabling a target in 
the configure script. Since this problem seems to be understood, you should 
aim for the right fix instead.

  Thomas

> În dum., 4 iul. 2021 la 05:30, Philippe Mathieu-Daudé <f4bug@amsat.org 
> <mailto:f4bug@amsat.org>> a scris:
> 
>     On 7/4/21 11:27 AM, Philippe Mathieu-Daudé wrote:
>      > On 7/4/21 11:03 AM, Philippe Mathieu-Daudé wrote:
>      >> On 7/4/21 12:06 AM, Richard Zak wrote:
>      >>> For MIPS (all sub-targets, 64-bit and EL) & xtensa(eb), the compiler
>      >>> complains about running out of memory. Best I can see, that's not what
>      >>> actually happens, but that's the error message. I was going to
>      >>> investigate this later, but this was the error which was causing the
>      >>> test with the Haiku VM with that corresponding make target. My
>     desktop &
>      >>> laptop have 64 GB, and I'm pretty sure it didn't get to that point.
>      >>>
>      >>>
>      >
>     /boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/8.3.0/../../../../x86_64-unknown-haiku/bin/ld:
>      >>> final link failed: memory exhausted
>      >
>      >> See how Haiku handles POSIX errno:
>      >>
>      >>
>     https://github.com/haiku/haiku/blob/master/headers/os/support/Errors.h
>     <https://github.com/haiku/haiku/blob/master/headers/os/support/Errors.h>
>      >>
>      >> #define B_GENERAL_ERROR_BASE   INT_MIN
>      >>
>      >> #define B_POSIX_ERROR_BASE     (B_GENERAL_ERROR_BASE + 0x7000)
>      >>
>      >> #define B_POSIX_ENOMEM  B_TO_POSIX_ERROR(B_POSIX_ERROR_BASE + 0)
>      >> #define E2BIG           B_TO_POSIX_ERROR(B_POSIX_ERROR_BASE + 1)
>      >> #define ECHILD          B_TO_POSIX_ERROR(B_POSIX_ERROR_BASE + 2)
>      >> ...
>      >>
>      >
>      > Same problem with Xtensa:
>      >
>      > static uint32_t errno_h2g(int host_errno)
>      > {
>      >     static const uint32_t guest_errno[] = {
>      >         [EPERM]         = TARGET_EPERM,
>      >         [ENOENT]        = TARGET_ENOENT,
>      >         [ESRCH]         = TARGET_ESRCH,
>      >         [EINTR]         = TARGET_EINTR,
>      >         [EIO]           = TARGET_EIO,
>      >         [ENXIO]         = TARGET_ENXIO,
>      >         [E2BIG]         = TARGET_E2BIG,
>      >         [ENOEXEC]       = TARGET_ENOEXEC,
>      > ...
> 
>     Annoyingly enough this is also how linux-user/syscall.c does
>     (thinking about code re-use):
> 
>     /*
>       * This list is the union of errno values overridden in asm-<arch>/errno.h
>       * minus the errnos that are not actually generic to all archs.
>       */
>     static uint16_t host_to_target_errno_table[ERRNO_TABLE_SIZE] = {
>          [EAGAIN]            = TARGET_EAGAIN,
>          [EIDRM]             = TARGET_EIDRM,
>          [ECHRNG]            = TARGET_ECHRNG,
>          [EL2NSYNC]          = TARGET_EL2NSYNC,
>          [EL3HLT]            = TARGET_EL3HLT,
>          [EL3RST]            = TARGET_EL3RST,
>     ...
> 
> 
> 
> -- 
> Regards,
> 
> Richard J. Zak
> Professional Genius
> PGP Key: https://keybase.io/rjzak/key.asc <https://keybase.io/rjzak/key.asc>

Re: [PATCH 1/2] Fix for Haiku

[Richard Zak]

[-- Attachment #1: Type: text/plain, Size: 4650 bytes --]

Regarding upside down text, where did that occur? I certainly didn't do
that intentionally. Maybe an encoding error somewhere?

I'll work on incorporating the changes in the patch file. I'll make another
post where the other configure changes are in place, without the target
exclude list.

În dum., 4 iul. 2021 la 12:23, Thomas Huth <thuth@redhat.com> a scris:

>
> Meta comment: Please avoid
> ƃuıʇsod uʍop ǝpısdn
> ... it makes threads much harder to read.
>
> On 04/07/2021 16.20, Richard Zak wrote:
> > Exactly. One of the developers on the Haiku forum shared with me the
> patch
> > that Haiku uses for qemu, and it has a few lines concerning error codes.
> > I'll look into this.
> >
> https://github.com/haikuports/haikuports/blob/14c2cab5428145b93232cb69683a67bbe68a9f06/app-emulation/qemu/patches/qemu-3.1.1.1.patchset
>
> So something like the change in target/xtensa/xtensa-semi.c is the right
> way
> to go - using a switch-case statement looks like the right fix instead of
> disabling the targets in the configure script.
>
> > This is a stopper for the configure script changes?
>
> Well, if anyhow possible, we should avoid hacks like disabling a target in
> the configure script. Since this problem seems to be understood, you
> should
> aim for the right fix instead.
>
>   Thomas
>
> > În dum., 4 iul. 2021 la 05:30, Philippe Mathieu-Daudé <f4bug@amsat.org
> > <mailto:f4bug@amsat.org>> a scris:
> >
> >     On 7/4/21 11:27 AM, Philippe Mathieu-Daudé wrote:
> >      > On 7/4/21 11:03 AM, Philippe Mathieu-Daudé wrote:
> >      >> On 7/4/21 12:06 AM, Richard Zak wrote:
> >      >>> For MIPS (all sub-targets, 64-bit and EL) & xtensa(eb), the
> compiler
> >      >>> complains about running out of memory. Best I can see, that's
> not what
> >      >>> actually happens, but that's the error message. I was going to
> >      >>> investigate this later, but this was the error which was
> causing the
> >      >>> test with the Haiku VM with that corresponding make target. My
> >     desktop &
> >      >>> laptop have 64 GB, and I'm pretty sure it didn't get to that
> point.
> >      >>>
> >      >>>
> >      >
> >
>  /boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/8.3.0/../../../../x86_64-unknown-haiku/bin/ld:
> >      >>> final link failed: memory exhausted
> >      >
> >      >> See how Haiku handles POSIX errno:
> >      >>
> >      >>
> >
> https://github.com/haiku/haiku/blob/master/headers/os/support/Errors.h
> >     <
> https://github.com/haiku/haiku/blob/master/headers/os/support/Errors.h>
> >      >>
> >      >> #define B_GENERAL_ERROR_BASE   INT_MIN
> >      >>
> >      >> #define B_POSIX_ERROR_BASE     (B_GENERAL_ERROR_BASE + 0x7000)
> >      >>
> >      >> #define B_POSIX_ENOMEM  B_TO_POSIX_ERROR(B_POSIX_ERROR_BASE + 0)
> >      >> #define E2BIG           B_TO_POSIX_ERROR(B_POSIX_ERROR_BASE + 1)
> >      >> #define ECHILD          B_TO_POSIX_ERROR(B_POSIX_ERROR_BASE + 2)
> >      >> ...
> >      >>
> >      >
> >      > Same problem with Xtensa:
> >      >
> >      > static uint32_t errno_h2g(int host_errno)
> >      > {
> >      >     static const uint32_t guest_errno[] = {
> >      >         [EPERM]         = TARGET_EPERM,
> >      >         [ENOENT]        = TARGET_ENOENT,
> >      >         [ESRCH]         = TARGET_ESRCH,
> >      >         [EINTR]         = TARGET_EINTR,
> >      >         [EIO]           = TARGET_EIO,
> >      >         [ENXIO]         = TARGET_ENXIO,
> >      >         [E2BIG]         = TARGET_E2BIG,
> >      >         [ENOEXEC]       = TARGET_ENOEXEC,
> >      > ...
> >
> >     Annoyingly enough this is also how linux-user/syscall.c does
> >     (thinking about code re-use):
> >
> >     /*
> >       * This list is the union of errno values overridden in
> asm-<arch>/errno.h
> >       * minus the errnos that are not actually generic to all archs.
> >       */
> >     static uint16_t host_to_target_errno_table[ERRNO_TABLE_SIZE] = {
> >          [EAGAIN]            = TARGET_EAGAIN,
> >          [EIDRM]             = TARGET_EIDRM,
> >          [ECHRNG]            = TARGET_ECHRNG,
> >          [EL2NSYNC]          = TARGET_EL2NSYNC,
> >          [EL3HLT]            = TARGET_EL3HLT,
> >          [EL3RST]            = TARGET_EL3RST,
> >     ...
> >
> >
> >
> > --
> > Regards,
> >
> > Richard J. Zak
> > Professional Genius
> > PGP Key: https://keybase.io/rjzak/key.asc <
> https://keybase.io/rjzak/key.asc>
>
>

-- 
Regards,

Richard J. Zak
Professional Genius
PGP Key: https://keybase.io/rjzak/key.asc

[-- Attachment #2: Type: text/html, Size: 6919 bytes --]

Re: [PATCH 1/2] Fix for Haiku

[Thomas Huth]

On 04/07/2021 18.39, Richard Zak wrote:
> Regarding upside down text, where did that occur? I certainly didn't do that 
> intentionally. Maybe an encoding error somewhere?

That was meant as a humorous way to say that you should avoid top posting, 
but apparently it was just confusing instead. Sorry for that. Anyway, we use 
interleaved posting on qemu-devel. See e.g.:

https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  Thomas

Re: [PATCH 1/2] Fix for Haiku

[Richard Zak]

[-- Attachment #1: Type: text/plain, Size: 828 bytes --]

În dum., 4 iul. 2021 la 12:51, Thomas Huth <thuth@redhat.com> a scris:

> On 04/07/2021 18.39, Richard Zak wrote:
> > Regarding upside down text, where did that occur? I certainly didn't do
> that
> > intentionally. Maybe an encoding error somewhere?
>
> That was meant as a humorous way to say that you should avoid top posting,
> but apparently it was just confusing instead. Sorry for that. Anyway, we
> use
> interleaved posting on qemu-devel. See e.g.:
>
> https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
>
>   Thomas
>

Ahh got it. I hadn't done that since Gmail wants to hide the test I'm
responding to. I'm assuming that revisions to a patch should still be a new
post, not in a reply?

-- 
Regards,

Richard J. Zak
Professional Genius
PGP Key: https://keybase.io/rjzak/key.asc

[-- Attachment #2: Type: text/html, Size: 1519 bytes --]

Re: [PATCH 1/2] Fix for Haiku

[Thomas Huth]

On 04/07/2021 18.58, Richard Zak wrote:
> 
> În dum., 4 iul. 2021 la 12:51, Thomas Huth <thuth@redhat.com 
> <mailto:thuth@redhat.com>> a scris:
> 
>     On 04/07/2021 18.39, Richard Zak wrote:
>      > Regarding upside down text, where did that occur? I certainly didn't
>     do that
>      > intentionally. Maybe an encoding error somewhere?
> 
>     That was meant as a humorous way to say that you should avoid top posting,
>     but apparently it was just confusing instead. Sorry for that. Anyway, we
>     use
>     interleaved posting on qemu-devel. See e.g.:
> 
>     https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
>     <https://en.wikipedia.org/wiki/Posting_style#Interleaved_style>
> 
>        Thomas
> 
> Ahh got it. I hadn't done that since Gmail wants to hide the test I'm 
> responding to. I'm assuming that revisions to a patch should still be a new 
> post, not in a reply?

Right, different revisions should go into a new post, with a version 
indication in the subject, e.g:

  [PATCH v3] Fix for Haiku

  Thomas