From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 112F238582A0 for ; Mon, 18 Dec 2023 12:44:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 112F238582A0 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 112F238582A0 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702903469; cv=none; b=GzWnJsrcdVDYpZalnxegQSdXTsRSYJQI0V9au3eIGEck6hX5xGUdKIUgnosFWlIbIbFBwbXTQR0lFZ3NA8o2G/nOPygYNuHu5e/Bz5SPX2PfGvd4q7kggir841sg19QB+jQrJqzLHQqAZHAnezyJaoLBng9y58sx3Qb4T8YXE88= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702903469; c=relaxed/simple; bh=HYxC6v5oOqv3gv2qRrpQUiRvXXLYUWMe6Lykp7ADglU=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=Qk4E0gOU/vH+Tfo3pWyjBcu1ozdVEjaIGatKGmRZQQBJysPtvnoXXnzw0ffecwe3CT/T7Uhns1Q+g+kqXhIQgwVOGHepYNFxEj8U+j/Ldc6nHdr2l3pTlmwj93A9t80ZrQPLxirizBo6pr/t4K4J+ZDz2C//qIrAa3ttxHhoYIA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1702903467; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qcuZGj6er7H7jxoH3Q5QKm4Xl6ZJ/FJRr1R/HxFG5Bo=; b=NTpvSJok7iPuBBwx3VW0NZTa1YbgFG6TVCGzb2EfQlsFiU06gZohXy0pGQ0I/kgyFuVQjZ z0blu9BxCpk0Vkbxvspf2r0A9nWcmzFC4VLByLaW5yxMcrkumNSWitnimO78oCjVPgLbmN mrItW8B/EOklUHHRj//1+LA+3041izg= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-312-JDbO8JJ7N9-ExzlSN1aI9g-1; Mon, 18 Dec 2023 07:44:26 -0500 X-MC-Unique: JDbO8JJ7N9-ExzlSN1aI9g-1 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-3365791d24eso1682805f8f.1 for ; Mon, 18 Dec 2023 04:44:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702903465; x=1703508265; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qcuZGj6er7H7jxoH3Q5QKm4Xl6ZJ/FJRr1R/HxFG5Bo=; b=qgygqcGE3bhtF0VDf3QwVQgAaI/zwIHpitFBCP5AEEQzSy0tAknQPQVUzOjcVQUGL+ xB/cvqPz0r4DhBS2DjoV00IhmzowXj1Tx2V/dcu9hVuJBXN4ZEakQzkZyHST+V2wxHle LUfrr+SC/+fIMamdEZvZrdpiHMbromAcHYkmIEYlSl9X3bAyYwjxJ4H378bGsvlJWg7C nsajWWyQkWD8buf+N0NGJ04dQYA8pRD+CC8Uxr9OCWlngQcycR97PECXJIBjQi1j50zW /VKEIIvbGMMZM7uhC0WjsiPTjU9IAE0sjeVKhoS8LUtsWfNaAKEZFLDB1s046/hU8NCd wL0g== X-Gm-Message-State: AOJu0YwuAbcflncvitUdpTKDlYXwOpRDJ9Pu2nhEfn7uJ+CnOBOUgnIt XOLkZ/AsPF3V3h4+jcgbocXik8oWbzNcKghSPRPh6Mm5AATVP8irF35DMZG3N/sfrl0paHTsZLA xq6e5VypUJM0kDg5DWl9dJA== X-Received: by 2002:adf:ef4e:0:b0:336:6913:61b3 with SMTP id c14-20020adfef4e000000b00336691361b3mr664524wrp.128.1702903465174; Mon, 18 Dec 2023 04:44:25 -0800 (PST) X-Google-Smtp-Source: AGHT+IHN4KJ7Vz13RTFAk2lRLoTQBfjQzl+tMXOe5ZkIbgMQrUAIjQF8quBhwgmU/jwmPKT+DqxeyQ== X-Received: by 2002:adf:ef4e:0:b0:336:6913:61b3 with SMTP id c14-20020adfef4e000000b00336691361b3mr664508wrp.128.1702903464802; Mon, 18 Dec 2023 04:44:24 -0800 (PST) Received: from localhost (105.226.159.143.dyn.plus.net. [143.159.226.105]) by smtp.gmail.com with ESMTPSA id h18-20020adffd52000000b003366af9d611sm1581620wrs.22.2023.12.18.04.44.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Dec 2023 04:44:24 -0800 (PST) From: Andrew Burgess To: Mike Frysinger 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 In-Reply-To: References: <20231030130042.1472535-1-jaydeep.patil@imgtec.com> <20231030130042.1472535-2-jaydeep.patil@imgtec.com> <87y1dze3m5.fsf@redhat.com> Date: Mon, 18 Dec 2023 12:44:23 +0000 Message-ID: <87sf3z4r4o.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Mike Frysinger writes: > 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. >> >> 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. I was referring to newlib the project rather than newlib the libc library. Which you figured out once you did a grep ... > 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 Yeah, it's a bit "yuck". The commit lives in the libgloss directory, but actually adds a parallel set of build rules that create a libsemihost.a as a separate thing from libgloss.a, hence my "separate to libgloss" comment. Which I'll argue is both correct and incorrect at the same time (correct: it's a separate library, incorrect: it's within the libgloss part of the newlib project tree). > > 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). I don't know why they are both defined at the same time. I guess that could be changed. I also don't know who implements either the semihosting syscalls, or the libgloss sys_* syscalls. > > 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) ? This is where things get even more iffy. As best I can tell the RISC-V semihosting spec is here: https://github.com/riscv-software-src/riscv-semihosting/blob/main/riscv-semihosting-spec.adoc But this looks far from complete to me. The commit that added semihosting to newlib (the project) can be found here: https://inbox.sourceware.org/newlib/694d497b-bc07-a3ba-2643-a7336927e9a7@embecosm.com/ Comments in that thread seem to indicate that the situation is more of a ad hoc standard, with (maybe) openocd being a first reference implementation? However, it is supported by QEMU with commit a10b9d93ecea0a8 (though I think there are additional follow up commits relating to this topic) so there are definitely other simulators supporting this out there. > >> 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 ? I haven't looked. I'll leave that as an exercise for Jaydeep. I'd be open to supporting both simultaneously as a first cut ... but I guess if you feel strongly then I'm not against making it a requirement for this to be switchable... it feels like that should be simple enough. > >> 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. For my own education; the ECALL handling does make use of sim_syscall. When you say: "the port, as written, isn't following our existing conventions for integrating with syscalls", do you mean the new semihosting port? Or are you saying the (pre-patch) existing code is also not using the standard sim syscall mechanism? The problem I see (at a quick glance) with the semihosting API is that the syscall arguments are read from memory, while the existing syscall mechanism seems to assume syscall arguments are in registers. My initial thoughts were that getting the semihosting support to use the existing mechanism might not be straight forward. Thanks, Andrew