Re: [Qemu-devel] [PATCH] target-xtensa: fix missing errno codes for mingw32

[Stefan Weil]

Am 06.09.2012 14:48, schrieb Max Filippov:
> On Thu, Sep 6, 2012 at 8:45 AM, Stefan Weil<address@hidden>  wrote:
> > Am 06.09.2012 02:36, schrieb Max Filippov:
> >
> > > Put the following errno value mappings under #ifdef:
> > >
> > > xtensa-semi.c: In function 'errno_h2g':
> > > xtensa-semi.c:113: error: 'ENOTBLK' undeclared (first use in this
> > > function)
> > > xtensa-semi.c:113: error: (Each undeclared identifier is reported only
> > > once
> > > xtensa-semi.c:113: error: for each function it appears in.)
> > > xtensa-semi.c:113: error: array index in initializer not of integer type
> > > xtensa-semi.c:113: error: (near initialization for 'guest_errno')
> > > xtensa-semi.c:124: error: 'ETXTBSY' undeclared (first use in this
> > > function)
> > > xtensa-semi.c:124: error: array index in initializer not of integer type
> > > xtensa-semi.c:124: error: (near initialization for 'guest_errno')
> > > xtensa-semi.c:134: error: 'ELOOP' undeclared (first use in this function)
> > > xtensa-semi.c:134: error: array index in initializer not of integer type
> > > xtensa-semi.c:134: error: (near initialization for 'guest_errno')
> > >
> > > Signed-off-by: Max Filippov<address@hidden>
> > > ---
> >
> > Is semi hosting a useful feature when QEMU runs on a Windows host?
>
> It should be if windows is POSIX enough.
>
> > If not, you could conditionally compile the whole semi hosting code
> > for non Windows only.
> >
> > If yes, what about the differences in system calls between UNIX like
> > operating systems and Windows? Should the code for 'open' add O_BINARY?
>
> ...otherwise \n will turn to \r\n? IIRC this behaviour was tunable at the system
> level under cygwin. Not under mingw?
>
> Is there a list of such differences?


Signed-off-by: Stefan Weil <address@hidden>

Blue, please take the patch as it is and commit it:
compilation for MinGW is currently broken, and the patch fixes that.

The system calls should be handled by a separate patch.

Yes, 'open' with MinGW opens files in text mode by default.
That implies automatic translation from \n to \r\n on writes
and vice versa on read. It also implies that seeking can give
unexpected results.

Or-ing the flags for open with O_BINARY would fix the problem
and works also for other OS were we define O_BINARY = 0.

Like Cygwin, MinGW also supports linking with binmode.o.
That file changes the default for open to binary mode,
so all open calls in QEMU would automatically be binary.

Maybe that second alternative is the better one.

I noticed that lseek takes an int32_t offset. Is this
intentional? It limits file size to 2 GiB.

I did not see other potential problems with the system calls.

Thanks,

Stefan W.