eiakov...@linux.microsoft.com writes:
> On 1/6/23 7:58 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: >> On Fri, 6 Jan 2023 at 18:22, Evgeny Iakovlev >> <eiakov...@linux.microsoft.com> wrote: >> > >> > >> > On 1/6/2023 17:28, Peter Maydell wrote: >> >> On Fri, 6 Jan 2023 at 15:44, Alex Bennée <alex.ben...@linaro.org> wrote: >> >>> Peter Maydell <peter.mayd...@linaro.org> writes: >> >> I think the theory when the semihosting API was originally designed >> >> decades ago was basically "when the guest does fopen(...) this >> >> should act like it does on the host". So as a bit of portable >> >> guest code you would say whether you wanted a binary or a text >> >> file, and the effect would be that if you were running on Windows >> >> and you output a text file then you'd get \r\n like the user >> >> probably expected, and if on Linux you get \n. >> > If SYS_OPEN is supposed to call fopen (i didn't actually know >> that..) >> > then it does make more sense for binary/text mode to be propagated from >> > guest. >> It's not required to literally call fopen(). It just has to >> give the specified semantics for when the guest passes it a >> mode integer, which is defined in terms of the ISO C >> fopen() string semantics for "r", "rb", "r+", "r+b", etc. >> > Qemu's implementation calls open(2) though, which is not correct >> > at all then. Well, as long as qemu does that, there is no >> > posix-compliant way to tell open(2) if it should use binary or text >> > mode, there is no notion of that as far as posix (and most >> > implementations) is concerned. >> QEMU doesn't have to be pure POSIX compliant: we know what our >> supported host platforms are and we can freely use extensions >> they provide. If we want to achieve the semantics that semihosting >> asks for then we can do that with open(), by passing O_BINARY when >> the mode integer from the guest corresponds to a string with "b" in it. >> I'm about 50:50 on whether we should do that vs documenting and >> commenting that we deliberately produce the same behaviour on all >> platforms by ignoring the 'b' flag, though. >> thanks >> -- PMM >> > > Thanks Peter, i think i see your point. However, if you ask me, i feel > like advertising a feature to guest code and only implementing it on 1 > platform that supports it just because it has a non-standard POSIX > implementation will only confuse the issue further. > Guest code doesn't want to care whether or not an emulator is running > on Linux or Windows, there is no notion of that leaking to guest code. > What it cares about is being able to consistently use a certain > feature in their code. > So i think it would be rather useless to implement it on Windows-only > given there is a clear alternative to switch to fopen. Just my 2 > cents. It's not switching to fopen() that is the issue - it's the interaction with gdb (via gdbstub) which has no idea about the distinction. Anyway I already have the patch queued with an additional note in the documentation that all file accesses are in binary mode. -- Alex Bennée Virtualisation Tech Lead @ Linaro
