From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id 335463858D3C for ; Wed, 13 Dec 2023 03:43:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 335463858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 335463858D3C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=140.211.166.183 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702439036; cv=none; b=gZ+YuMRoEIa4jPOkkoX1hzgZ4C0bJU+KvWxbIGnyvrOj08SeY5MZjiOE+c56rT/We+X/oYAwXSIXOwJSBAkGQT0yn2qalx/j6roV2xtpbXAxtZjVWvQpI0C2gwDxjQRi1v0kWC/UJ662WTPiU0afxqqxMalTedg1NGHrYKK3/jk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702439036; c=relaxed/simple; bh=iH7ic6msg3saK7LQQttrl2xZS0NBoOe7B5U1Oau+3yQ=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=drENu8/8UujvDUXEU2E0dro3pwbRdsMUElVm69+G/WdOCjj0abFfVdkRORh12xPeMkLocY9I9zxnx5szfp4ctqNtfupo5rFZMEs0YwFl1xJ8tacROFiDgVKnKcgcM3PKFV5bcsYSH/4YYZyhB1P8xhgMZowDy8TrB3EOKWGJs+4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by smtp.gentoo.org (Postfix, from userid 559) id B0F67335DC3; Wed, 13 Dec 2023 03:43:54 +0000 (UTC) Date: Tue, 12 Dec 2023 22:43:53 -0500 From: Mike Frysinger To: Andrew Burgess Cc: jaydeep.patil@imgtec.com, gdb-patches@sourceware.org, joseph.faulls@imgtec.com, bhushan.attarde@imgtec.com Subject: Re: [PATCH v2 1/3] [sim/riscv] Add basic semi-hosting support Message-ID: References: <20231030130042.1472535-1-jaydeep.patil@imgtec.com> <20231030130042.1472535-2-jaydeep.patil@imgtec.com> <87y1dze3m5.fsf@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pNPM7otaegiq99xw" Content-Disposition: inline In-Reply-To: <87y1dze3m5.fsf@redhat.com> X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --pNPM7otaegiq99xw Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 12 Dec 2023 17:24, Andrew Burgess wrote: > Mike Frysinger 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. >=20 > 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=3Dnewlib-cygwin.git;a=3Dcommit;h=3D865cd30dcc= 2f00c81c8b3624a9f3464138cd24a5 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 interf= ace 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 d= own that hole, i wanted to understand at a higher level the diff between the tw= o. the patch def needs a lot of work either way. -mike --pNPM7otaegiq99xw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmV5KHMACgkQQWM7n+g3 9YEZrg//TAUU4W+2ImCXEimJJW/SdmWrLP6oq1gkfILAjHKzr/dzGOiue5XGIAN2 7bI04fmKsc6zJE03Xh7C5vUOYuabPDvE7KsZVzciWAVCwFG4YefQhlxr7kWqsSEL DS9TQcA0wgRriBN+K8XL6dk8SpeFJ8scqHWK3H3rNZgQFMZUFbaS+uGQMYee8i1Y U1yfb7qA51D/tlkzk5EslVJiyfclekp7Zn299J7vXvSGELyygz3Rhvf9tgBF7dde lHSAxrUWUbhPo0MoXWYLmIBWRwtcNSWwzi26lLr6zkXZ1pelBN3CNafbW3IlvH4Q /zMdD2fVVkz0w6RGjArWfwW68zGN3tfIS0yZGQd7xH0Jz+tiqciYE4uiFfmHwve7 tQYwjXTzxu180aM0JOeuCIK9hp/kbZJ0LRGWttdnNdvO8HT5hjtkIix4f8lQIn2v HeeIUWwiK5IlZKpldkoPLZXzp7aGoXx6CgzYG2lGsRzmk4AsGZZ58+RcbXBVj/8h 89k+O0fmqNkPALBc1f2L/aZhbA94Mn5nLmQyf88bMdjhVW7ewEdiD6E0lMaWO9D5 dx9FujKygAmenFy2HYSCe0ux8Iq2LNmg8yVKu2f3djuur9KQdFCJ68upQLy94mrn 1Y8QjPkLPtRssjl7XCXmde6sAZ/Dpc5k8qTpapYPhWJuD9ibfjE= =GvC5 -----END PGP SIGNATURE----- --pNPM7otaegiq99xw--