From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from beige.elm.relay.mailchannels.net (beige.elm.relay.mailchannels.net [23.83.212.16]) by sourceware.org (Postfix) with ESMTPS id 93B013858025; Sun, 25 Apr 2021 22:29:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 93B013858025 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=eagercon.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=eager@eagercon.com X-Sender-Id: dreamhost|x-authsender|eager@eagerm.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id EEF28481CB3; Sun, 25 Apr 2021 22:29:52 +0000 (UTC) Received: from pdx1-sub0-mail-a46.g.dreamhost.com (100-105-161-122.trex.outbound.svc.cluster.local [100.105.161.122]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 6D7BF481CCB; Sun, 25 Apr 2021 22:29:52 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|eager@eagerm.com Received: from pdx1-sub0-mail-a46.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.105.161.122 (trex/6.2.1); Sun, 25 Apr 2021 22:29:52 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|eager@eagerm.com X-MailChannels-Auth-Id: dreamhost X-Duck-Absorbed: 2c81cee96e8212b4_1619389792815_3339875937 X-MC-Loop-Signature: 1619389792815:1063138582 X-MC-Ingress-Time: 1619389792815 Received: from pdx1-sub0-mail-a46.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a46.g.dreamhost.com (Postfix) with ESMTP id 334AC8D0C3; Sun, 25 Apr 2021 15:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=eagercon.com; h=subject:to :references:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=eagercon.com; bh=vuud ElJ2SXbxL32hiTYMt8JPBFw=; b=UF8Q3UqfxsC6qhTxDV4DGDdqBrMph6XSJrWz LjJ7eOIkRyYKUGzdTVrpMOZNcFvW8JG2icM7q7grfN881mBBEOVcp9EM7e71RFrl qMnBzqvcU6jkXKBJsj06X3VJ4eTy/aaIkk9bPcDmVuzRIC6s4jUesosYwWDx6bk3 XonyC60= Received: from [192.168.20.41] (c-24-6-12-13.hsd1.ca.comcast.net [24.6.12.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: eager@eagerm.com) by pdx1-sub0-mail-a46.g.dreamhost.com (Postfix) with ESMTPSA id 83CD68B7CE; Sun, 25 Apr 2021 15:29:50 -0700 (PDT) Subject: Re: Microblaze libgloss and gdb simulator To: Joel Sherrill , gdb@sourceware.org, Newlib , vapier@gentoo.org References: <30fc7511-5f60-e611-d732-57cdaad80107@eagercon.com> X-DH-BACKEND: pdx1-sub0-mail-a46 From: Michael Eager Message-ID: <6d72dbe2-efe3-f8ba-3c2b-0c248883649b@eagercon.com> Date: Sun, 25 Apr 2021 15:29:49 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2021 22:29:56 -0000 On 4/25/21 1:27 PM, Mike Frysinger wrote: > On 25 Apr 2021 11:37, Michael Eager wrote: >> On 4/25/21 10:21 AM, Mike Frysinger wrote: >>> On 24 Apr 2021 01:02, Mike Frysinger via Gdb wrote: >>>> On 22 Apr 2021 21:19, Mike Frysinger via Gdb wrote: >>>>> On 22 Apr 2021 19:55, Joel Sherrill wrote: >>>>>> On Thu, Apr 22, 2021, 7:27 PM Mike Frysinger wrote: >>>>>>> ignoring that, the microblaze sim doesn't have syscall support hooked up. >>>>>>> so it's only a CPU simulator atm. >>>>>> >>>>>> So it has no output whatsoever? Does it get used for anything? >>>>> >>>>> afaict, correct. the most basic sims just do CPU level stuff and then have >>>>> their state inspected, or communicate pass/fail via exit status or abort. >>>>> this behavior actually isn't that rare ... it's where most sims start. >>>>> >>>>>> We are resurrecting some old work that I did for a Microblaze port. I did >>>>>> write an inbyte() and outbyte() which would normally come from the xil >>>>>> library. But I don't have any idea how I figured out there was a uart at a >>>>>> particular address. I swear I had it working to print then but now it >>>>>> faults after the first instruction. >>>>>> >>>>>> Is there any known good executable for it? Even just seeing it operate with >>>>>> a linked executable that had a crt0 and did something would be helpful at >>>>>> this point. >>>>> >>>>> ftr, i've never worked on microblaze. i'm just reading the code and poking >>>>> the toolchain :). >>>>> >>>>> getting i/o (or maybe just o) support into the sim shouldn't be terribly hard. >>>>> we could even do the normal libgloss syscalls. the important things we need to >>>>> know are: >>>>> * how does outbyte work ? is it writing to MMIO UARTs, or something else ? >>>>> * is there an interrupt or exception or specific insn that microblaze uses to >>>>> trigger the hypervisor/monitor/whatever ? if so, should be possible to wire >>>>> that up in the microblaze port. my reading of libgloss/microblaze/ isn't >>>>> picking out anything interesting, but i'm by no means an expert here. >>>>> >>>>> if you can figure out those bits, happy to help on the sim side. >>>> >>>> here's wiring up the syscall path, but it's unclear whether we should do this >>>> without changes landing in libgloss first. >>> >>> Michael: what do you think of wiring up the libgloss syscalls for microblaze >>> via the brki insn ? is there any prior art in this space for microblaze ? >>> i wouldn't want to try an allocate syscall space that's already used. >> >> I never did anything with the SIM code for Microblaze. I always used a >> proprietary instruction set simulator provided by Xilinx. > > the git history says it came from you :) > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=bd30e45a3430ce30c63146aa8cad0796754581b6 Yeah. Other than submitting it upsteam, I don't think I did anything with the simulator. >> I would not use a BRKI instruction, since the ABI has documented >> its behavior. Someone might write code which depends on this. >> >> Microblaze doesn't have a system call instruction. I would pick an >> undefined op code and treat this as a SYS instruction, interpreting >> it as call to libC or other system functionality. >> >> This may (or may not) be helpful: I implemented something similar to >> this in QEMU for Qualcomm/Ubicom, where a SYSCALL (or some such) >> instruction was translated into read, write, and other system calls. It >> was modeled on similar semihosting support in ARM, if I recall >> correctly. IIRC, functions in libgloss were thin wrappers around >> the SYSCALL instruction. > > the manual says for BRKI: > Application (user-mode) programs transfer control to system-service routines > (privileged mode programs) using the BRALID or BRKI instruction, jumping to > physical address 0x8. Executing this instruction causes a system-call exception > to occur. The exception handler determines which system-service routine to call > and whether the calling application has permission to call that service. > If permission is granted, the exception handler performs the actual procedure > call to the systemservice routine on behalf of the application program. > ... > When MicroBlaze is configured to use an MMU (C_USE_MMU >= 1) this instruction > is privileged, except as a special case when "brki rD, 0x8" or "brki rD, 0x18" > is used to perform a Software Break. This means that, apart from the special > case, if the instruction is attempted in User Mode (MSR[UM] = 1) a Privileged > Instruction exception occurs. > > isn't this a syscall handler ? this is how Linux implements things too. > https://man7.org/linux/man-pages/man2/syscall.2.html#NOTES > microblaze brki r14,8 r12 r3 - - > > libgloss has: > # define SYSCALL_BODY(name) \ > addik r12, r0, SYS_ ## name; \ > brki r14, 8; \ > rtsd r15, 8; \ > nop; > -mike It depends on what code you are simulating. If you are simulating a program which uses libgloss and you expect the behavior of brki to be a syscall, then this is a very reasonable way to implement system calls. Instead of taking the branch to the handler, the simulator does whatever host system call it is supposed to do, then returns, just as if there was an OS handling the system call. (This is what QEMU calls "semihosting".) I was thinking about the more general case, where you might be simulating an image which includes an exception handler. In this case, the behavior you want is to take the exception and jump to the excption handler address, instead of the simlator interpreting the brki as a syscall. -- Michael Eager