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.129.124]) by sourceware.org (Postfix) with ESMTPS id 4C6803858413 for ; Fri, 7 Jan 2022 10:43:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4C6803858413 Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-589-j9O_a-rWPzal1Ps44fm3Mw-1; Fri, 07 Jan 2022 05:43:25 -0500 X-MC-Unique: j9O_a-rWPzal1Ps44fm3Mw-1 Received: by mail-wm1-f69.google.com with SMTP id b9-20020a7bc249000000b00347c5699809so431804wmj.1 for ; Fri, 07 Jan 2022 02:43:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Bo96UkbGQa3xq+7ACQoUNO6Djns+IQx9lBKS/ganPEE=; b=fr3gMWjh40mSlecy47SjKmh2GPYP8yG45xRvK0iVXyH24fBfPwJ6WJEgdTzj0YqvOz YCJr4BmgrBAfhjsCvko6GbuIt+4O3d36iOfq7EekcwrCgHonw8APtcCyUQLhoZ0gcbCO rx70GPBVdrL7M0H3u1qiDEigsh4jYXUrO13RJeP7+b5HosTxe9OOEJudr0QZ691Lq0Uq 9UXtPByrpUmHgvnxh9MVbwnZij1eFtugSVvuQyMBUtFtrjyl0IABDd5kRlDvgH2CS0gy WkhaTUdI2DhIdVrA8nGR2yigQ8DZDIgFHjQpdrm0IxdJcW/IVqMb6xZU5nZ/OLrCRBdx tO0A== X-Gm-Message-State: AOAM530BYab2MfEusJvPE5rsIo0mJyCsOdXGNnsSWult2jRbmn99NnW1 t4UjR/9uYF5Jd2ukStLD3xvLzS4JwW3EVWC+9d9e2purTWLJ0D4TopNiCfXor68c27KhhwCAxIv SJgLKQHutCIk= X-Received: by 2002:adf:e98f:: with SMTP id h15mr2367476wrm.342.1641552203748; Fri, 07 Jan 2022 02:43:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJzhqlws7ALcPqMNeLOSEHHsEw3m5GbCrb0EvND4yJOJEfky/r3RVOdiELuUcszA8kZy+lSSxA== X-Received: by 2002:adf:e98f:: with SMTP id h15mr2367461wrm.342.1641552203496; Fri, 07 Jan 2022 02:43:23 -0800 (PST) Received: from localhost (host109-154-163-67.range109-154.btcentralplus.com. [109.154.163.67]) by smtp.gmail.com with ESMTPSA id n41sm4430703wmr.3.2022.01.07.02.43.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Jan 2022 02:43:23 -0800 (PST) Date: Fri, 7 Jan 2022 10:43:21 +0000 From: Andrew Burgess To: "S. Champailler" Cc: gdb@sourceware.org Subject: Re: 6502 support in GDB Message-ID: <20220107104321.GC2492@redhat.com> References: <34b35bd0.606c.17e33e5b812.Webtop.188@skynet.be> MIME-Version: 1.0 In-Reply-To: <34b35bd0.606c.17e33e5b812.Webtop.188@skynet.be> X-Operating-System: Linux/5.8.18-100.fc31.x86_64 (x86_64) X-Uptime: 10:10:24 up 5 days, 19:04, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Fri, 07 Jan 2022 10:43:33 -0000 * S. Champailler via Gdb [2022-01-07 10:36:39 +0100]: > > Hello, > > > I was wondering if it is "easy" to add support for a CPU in GDB. > Specifically the 6502. > I'm mostly interested in debugging some assembly code I have written. My use > case > is : I write some assembly, compile it, run it in an emulator and use GDB to > remote > connect to that emulator and do remote debugging. > > Before posting this I've checked the mailing list archives and the git > history and it seems > it has never been done before. I've read the documentation a bit and swa one > talks about > adding an architecture (wiki page of the "internals" manual). Is that the > right place to start ? > > I had a few questions: > > - how big an effort is it ? Are we talking about weeks, months ? I bet > months. This will > be a hobby project, so it has some chances of failing if it proves too hard > to do. If you've never worked on binutils-gdb before then its likely to take a while yes, as there's a lot you'll need to figure out, though asking specific questions is always a good idea. You can always look in the repository to see what was done when initial support for other architectures was added, for example in commit dbbb1059e62e9f I added initial RISC-V support to GDB, something like this might provide a starting point. However, the above commit was only the GDB side of things, you need to at a minimum teach bfd about your architecture, and, if you're only going to be debugging assembler, as you say below, you'll likely want a disassembler (that's in the opcodes directory). There's lots of different approaches for writing the disassembler, some people make use of CGEN[1], but others just write their own from scratch. It doesn't really matter, so long as you supply the disassembler API. If your existing assembler produces ELF files (or maybe other structured formats, though I know little about non-ELF) then you might want to teach bfd about how to read them for your architecture, then tools like objdump, objcopy, will work. But I suspect you can probably skip that if you wanted, and just debug the image on the remote target, though you'd be stuck debugging by address - there's usually no debug information in a binary image. > - I understand I have to write a disassembler at the very least, is that > correct ? Discussed above. > - I understand I have to modify the emulator to provide a GDB remote access, > correct ? Yikes, that's a non-trivial task in itself. The full remote protocol is documented here[2], it's probably worth a read before you start any work. But you certainly don't need to implement everything to get something simple working. There's a (not quite old) guide to writing gdbservers here[3] which includes some recommendations for which packets to start with. Like I say, its pretty old, but could be worth a read. The other option would be to import your emulator into GDB. GDB has a 'target sim', see the sim/ directory. This might be quicker if you have the emulator source. > - I've checked DWARF but I still don't get how to connect my ASM source to > the actual disassembly, > does GDB provide help here ? (that is, when I'm pointing at my assembly > source code line, > I'd like to know to which instruction it corresponds in the 6502 code; same > stuff with symbols) GDB can consume the DWARF, but for creating the connection, that's the job of the assembler. Usually, in production tools based on the GNU stack, you'd use 'as' (see gas/ directory) to assemble your assembler files to ELF object files, then use 'ld' (see ld/ directory) to link them into a single ELF executable. If you assemble with the -g flag you'll get debug information in DWARF format embedded in the final executable. For baremetal targets you often need a binary blob, so you'd use objcopy to pull the blob out of the ELF ready to load onto your target. But, importantly, the addresses in the ELF would accurately reflect where the binary blob will be loaded, and so, the DWARF will correctly map addresses to lines. Now, GDB will read the DWARF (this is already handled, you'd need to make no changes), and can map things back to your assembler file. That said, there's nothing to stop GDB attaching to a remote target, disassembling memory, placing breakpoints (at addresses), and doing things like continue, or stepi, without any DWARF or ELF at all. I think your biggest hurdle will be deciding how you want GDB to interact with the target, neither approach is trivial. Your choices seem to be add a gdbserver to your emulator, or port your emulator to the gdb simulator framework. Personally I'd probably go with the gdbserver approach, but I don't think there's a "wrong" answer. Not sure if any of the above actually helps at all, Good luck, Andrew [1] https://sourceware.org/cgen/ [2] https://sourceware.org/gdb/onlinedocs/gdb/Remote-Protocol.html [3] https://www.embecosm.com/appnotes/ean4/embecosm-howto-rsp-server-ean4-issue-2.html