On 12 Dec 2023 17:24, Andrew Burgess wrote:
> Mike Frysinger <vapier@gentoo.org> writes:
> > On 30 Oct 2023 13:00, jaydeep.patil@imgtec.com wrote:
> >> Added support for basic semi-hosting calls OPEN, EXIT and GET_CMDLINE.
> >
> > what host environment are you implementing ?  none of the syscalls you've
> > defined match what have long been in the riscv libgloss port.  those are
> > the only ones i'd really expect at this point to be wired up.
> 
> This would be the RISC-V semihosting target, which is included in
> newlib (since 2020), but is separate to libgloss.

included where exactly ?  newlib/libc/machine/riscv/ has no syscalls afaict.
the word "semi" doesn't really appear anywhere in the codebase.

if you're referring to this commit, it's in libgloss, not newlib.
https://sourceware.org/git/?p=newlib-cygwin.git;a=commit;h=865cd30dcc2f00c81c8b3624a9f3464138cd24a5

looking at libgloss/riscv/machine/syscall.h, i see it defines the two sets
in parallel -- SYS_xxx and SEMIHOST_xxx.

the question is why does libgloss have both ?  if the riscv libgloss SYS_xxx
are only used by libgloss, and no one is implementing that (the sim hasn't),
and SEMIHOST_xxx are used by everyone, why not only use the semihost interface
and drop the SYS_xxx (and rename SEMIHOST_xxx to SYS_xxx).

where exactly is the riscv semihost standard defined such that people are
implementing the same API (source files) & ABI (the stub that processes the
ebreak calls) ?

> Where libgloss syscalls use ecall, the semihosting uses ebreak with two
> specific nop instructions (one before, one after the ebreak).

the calling convention doesn't really matter to the sim.  it can do either.

the question is whether we want to support them simultaneously, or only one
at a time.  what are other stubs doing ?

> Do you see any reason why we can't support both of these syscall
> libraries?  Potentially we could have a switch to select between them,
> but I'm inclined to say we should just support both until someone comes
> with a use-case where supporting both is a bad idea...  But maybe you
> have some deeper insights here.

supporting them both isn't a problem.  the port, as written, isn't following
our existing conventions for integrating with syscalls, but before i went down
that hole, i wanted to understand at a higher level the diff between the two.
the patch def needs a lot of work either way.
-mike