Map errno to fixed values

[quic-k]

Problem :

this is what happens currently

LIBC that compiles QEMU 
(provides errno macros)

  |
  |
  v
  
  QEMU
  (gets errno macros and sends them to LIBC that is using semi-hosting interface)
  
    |
    |
    v
    
    LIBC that is using semi-hosting
    (uses the errno values received from semihosting interface)

because the LIBC that compiles QEMU and the LIBC that is using semi-hosting are different, it is possible that we misinterpret the errno value
Example:
LIBC that compiles QEMU says :

#define EPERM 1
#define EACCES 2

LIBC that is using semi-hosting interface :

#define EPERM 2
#define EACCES 1

so if errno is set to EPERM by LIBC that compiles QEMU, it will be read as EACCES by the LIBC that is using the semi-hosting interface

Solution :

Map A->B in QEMU and then B->C in LIBC that is using semi-hosting
Here,
A : errno values in LIBC that compiles QEMU
B : fixed errno values defined by Hexagon semi-hosting spec
C : errno values in LIBC that is using semi-hosting interface

What happens when we do this mapping:

LIBC used to compile QEMU 
(provides errno macros)

  |
  |
  v
  
  QEMU
  (gets errno macros and converts them to TARGET_HEX_* values before sending to C library using semi-hosting)
  
    |
    |
    v
    
    C library using semi-hosting
    (converts TARGET_HEX_* values to its local errno values)

Note : The TARGET_HEX_* enum values are similar to errno macros in Dinkumware to ensure compatibility.
We can document these constants in Hexagon semihosting spec

[quic-k]

@quic-mathbern
@androm3da
@SidManning

[quic-mathbern]

I understand the motivation, and it makes sense to me. I wonder if there was no previous discussions about this libc/errno mismatch between guest and host on the mailing list before? If not, we could consider sending the patch there, instead.

Anyways, if we decide to move forward with this approach, not that we also have to map the values from the arm-compatible semihosting interface (see semihosting/arm-compat-semi.c ), which is used by qemu-hexagon as well.

[SidManning]

What is the reasoning behind the order below?

[quic-k]

none, I just copied them in order they were defined in dinkumware
but yes we can fix that before merge, this PR was more of a proposal

[quic-k]

I understand the motivation, and it makes sense to me. I wonder if there was no previous discussions about this libc/errno mismatch between guest and host on the mailing list before? If not, we could consider sending the patch there, instead.

Anyways, if we decide to move forward with this approach, not that we also have to map the values from the arm-compatible semihosting interface (see semihosting/arm-compat-semi.c ), which is used by qemu-hexagon as well.

https://github.com/qemu/qemu/blob/master/linux-user/generic/target_errno_defs.h
https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L562
QEMU does this errno mapping for user mode

for system mode, I can see MIPS and xtensa do this explicitly, I am not sure how others do this
https://github.com/qemu/qemu/blob/master/target/mips/tcg/system/mips-semi.c#L127
https://github.com/qemu/qemu/blob/master/target/xtensa/xtensa-semi.c#L98

[quic-k]

regarding semihosting/arm-compat-semi.c
https://developer.arm.com/documentation/dui0471/i/semihosting/sys-errno--0x13-?lang=en
says that "Whether errno is set or not, and to what value, is entirely host-specific, except where the ISO C standard defines the behavior."
which kind of suggests errno mapping is not done, I am bit confused by this

qemu-hexagon should use linux-user/syscall.c for semi-hosting, right?
isn't semi-hosting/ exclusively for system mode?
I am bit new to QEMU codebase

[quic-mathbern]

regarding semihosting/arm-compat-semi.c https://developer.arm.com/documentation/dui0471/i/semihosting/sys-errno--0x13-?lang=en says that "Whether errno is set or not, and to what value, is entirely host-specific, except where the ISO C standard defines the behavior." which kind of suggests errno mapping is not done, I am bit confused by this

qemu-hexagon should use linux-user/syscall.c for semi-hosting, right? isn't semi-hosting/ exclusively for system mode? I am bit new to QEMU codebase

Sorry, what I meant by "qemu-hexagon" is "the hexagon version of qemu". I should have said "qemu-system-hexagon"

[quic-akaryaki]

@quic-k why did you close this?

[quic-k]

@quic-akaryaki was trying to rebase, it closed automatically, I will reopen it