From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailsec218.isp.belgacom.be (mailsec218.isp.belgacom.be [195.238.22.114]) by sourceware.org (Postfix) with ESMTPS id DA4DD3858013 for ; Fri, 7 Jan 2022 10:58:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DA4DD3858013 X-ExtLoop: 1 X-IPAS-Result: =?us-ascii?q?A2AIBgBjHNhh/x4FIwpaHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?VmDJlIEbAuEPJBuJQOBE502CwEBAQEBAQEBAUAHAQIEAQGFBgKDQAElOBMBA?= =?us-ascii?q?gQBAQEBAwIDAQEBAQEBAwEBBgEBAQEBAQUEAYEbhS85DYI1KQGDZAEBAQIBD?= =?us-ascii?q?hUVLQkLEAgDDgQIAiYCAkkOBhOCf4J2JQuud4ExgQGJdAaBECqGDBNBgWiFa?= =?us-ascii?q?kOBSUSBFAEzAYI/Nz6CTBcDgUcYLIJsgmUEjzVrHRdhARsIBgIFGzCBCgUFH?= =?us-ascii?q?js6A5F1mnORKIEtBwMEgz6KdZRTBS6DcJIyL5EYk2mCT4JEh3aCRpNzKoU3A?= =?us-ascii?q?YF0gX1tU4JpURcRjiwWg1CFFIVLQzACNgIGAQoBAQMJhWIIiCQBgQ8BAQ?= IronPort-PHdr: A9a23:xsZnlRwDf8s42a3XCzK4zVBlVkEcU1XcAAcZ59Idhq5Udez7ptK+Z hWZvKk0xwWRFazgqNt8w9LMtK7hXWFSqb2gi1slNKJ2ahkelM8NlBYhCsPWQWfyLfrtcjBoV J8aDAwt8H60K1VaF9jjbFPOvHKy8SQSGhLiPgZpO+j5AIHfg9qq2+yo5pHebBhEiDWjbb9uM R67sRjfus4KjIV4N60/0AHJonxGe+RXwWNnO1eelAvi68mz4ZBu7T1et+ou+MBcX6r6eb84T aFDAzQ9L281/szrugLdQgaJ+3ART38ZkhtMAwjC8RH6QpL8uTb0u+ZhxCWXO9D9QKsqUjq+8 ahkVB7oiD8GNzEn9mHXltdwh79frB64uhBz35LYbISTOfFjfK3SYMkaSHJfUMhSVSNBDJ6yY IQTAOQOM+lYronzqVUVoBuiHAmhHv/jxiNSi3L026AxzuQvERvB3AwlB98CvmnaoM/oP6oMU eC61qzIzS3ZYPNX3Tf97JbHcgovrfqRWr9watbeyUk1GAPAllWfs43lPzeR1usTqWiW9PFgV eGvim4htQ5xviKjydwyhYTQgI8e11/L+zljzokvOd24VFB0YcSiEJZIqSyUOJZ7TMwiTm11u Cs3170LtIKlcCUExpkpyRzSZ+CZf4SU/B7uVeScLzhmiH9mZr6ymRm8/VWjx+DhVMS5zFBHp TdLnNnLs3ACzR3T6s6fR/tm+UehxCyP2BzN5eBKO080j7TUJ4Qmwr4qmZofqVrMHirtl0rok KCWcV4k+u2y5+v7ZbXmo5mRPJJ3hAHmKqkih9CzDf42PwUORWSW+f6w2bP/8UHhQ7hHjOc6n 6jWvZzAOMgWp6+0DxVI3oss6RuyCSqt3s4CknkdNl1FfQqKj43uO17TPv/1Fey/g1GwkDdzw PDGI6HhDo3NLnfdlLfheq5w60tGxwoyydBe6YxbBaodLP7vWkL9rcfYDgElPACswubnDsty1 p8GVG6SHqOVKq3fvF+S6u8vOeWBapMZtC74K/c/5v7uiXE5mUUafamsxZYXc2y3HvR8LEWce XrjmNYBEWMOvgUgVuznk0aCUT1TZna0Qa08+is3B5m4AovbXICinKSB3DunHp1Rfm1JEEuDE Wryd4WLRfgMczmSL9R7kjMaSLehS5Uu1Q20uADmzLpnK/Le+jcEupL7yNh1++rTmAk99TNpF MuQyHqNT2ZpnmMSWzA5wq5+rlZnylidy6R4hOZYFdMAr89OBy48OYTR0KRQFsr9VxnaNoOAQ ku8Tdi9GhkrQ94xysNIaEF4TYaMlBfGimCRRfc+l7WOHJU19qbRxTK5c912y3/DzKAgi10rW ONUNnygi7I5/QWFVN2BqFmQi6v/LfdU5yXK7mrWiDPW5Cll IronPort-Data: A9a23:6W2ilaJ/6iJvFEscFE+RTpclxSXFcZb7ZxGr2PjKsXjdYENS3jACm mMYUGmBbK2LamXxKt1+YYrn/R4HvJSEndVrTgQd+CA2RRqmiyZl6fd1j6vUF3nPRiEWZBs/t 63yUvGZcIZsCCa0Si6FatANl1ElvU2zbue6WL6s1hxZH1c+En940U07wobVv6Yx6TSHK1LV0 T/Ni5CHULOV82Yc3rU8sv/rRLtH5ZweiRtA1rAMTakjUGz2yxH5OKkiyZSZdBMUdGX78tmSH I4vxJnhlo/QEoxE5tmNyt4XeWVSKlLe0JTnZnd+A8CfbhZ+SiMajr0bO/8ZZ2Jtl2uHxMAg0 u9o77vzcFJ8VkHMsLx1vxhwFih/ObJL8ueffD2kr8f7I0/uKiOqmKgoUQdtZeX0+c4uaY1K3 ecTKDkIdhmCg+a72pqgSfhqi9hlJsSD0IY34yE7lWiDUq1OrZbrTK70vYQD4xIMu90QOu6dP JYpSxgoRUGVC/FIEhJNYH4kp8+hjGTlfDBDs3qPqKY36nSVxwt0uJDiPND9YduXX85YgU+Cq yTB5WuRP/0BHNmWyD6a/3j03rKJgSi9U4UIDNVU68JXvbFa/URLYDV+aLdxiaDRZpKWMz6UF 6DYFufCY0T/GIxHg+QRhyGFnUM= IronPort-HdrOrdr: A9a23:hNb2p67l2FMJ2NTotAPXwMDXdLJyesId70hD6qkRc3Fom6mj/K qTdZsguiMc9wxhOk3I9ergBED4ewK4yXcX2+Us1NWZMjUO0VHARL2KhrGSoAEIdRefygZVvZ 0QF5RDNA== X-IronPort-Anti-Spam-Filtered: true Received: from mailweb005.tc.corp (HELO mailweb005-svc) ([10.35.5.30]) by privrelay.glb.bgc.bc with ESMTP; 07 Jan 2022 11:58:20 +0100 Received: from [87.64.166.147] by webmail.ux.proximus.be with HTTP; Fri, 7 Jan 2022 11:58:19 +0100 To: Andrew Burgess Cc: gdb@sourceware.org Message-ID: <6164dcf.632c.17e34307c5c.Webtop.188@skynet.be> In-Reply-To: <34b35bd0.606c.17e33e5b812.Webtop.188@skynet.be> References: <34b35bd0.606c.17e33e5b812.Webtop.188@skynet.be> Subject: Re: Re: 6502 support in GDB MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=no Content-Transfer-Encoding: quoted-printable User-Agent: OWM Mail 3 X-SID: 188 X-Originating-IP: [87.64.166.147] From: "S. Champailler" Date: Fri, 7 Jan 2022 11:58:19 +0100 (CET) X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, 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:58:24 -0000 Thx for your reply. It's very complete and, well, intimidating :-) I'll think about it twice before starting :-/ Considering the time I spend actually debugging and the time it'd take to update GDB, I'm afraid the balance is tilted on the very wrong side.... unless it proves real fun to do... Thank again for your time. St=C3=A9phane ------ Message d'origine ------ De: aburgess@redhat.com To: schampailler@skynet.be Cc: gdb@sourceware.org Envoy=C3=A9: vendredi 7 janvier 2022 11:43 Objet: Re: 6502 support in GDB * S. Champailler via Gdb [2022-01-07=20 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=20 written. My use > case > is : I write some assembly, compile it, run it in an emulator and=20 use GDB to > remote > connect to that emulator and do remote debugging. > > Before posting this I've checked the mailing list archives and the=20 git > history and it seems > it has never been done before. I've read the documentation a bit and=20 swa one > talks about > adding an architecture (wiki page of the "internals" manual). Is=20 that the > right place to start ? > > I had a few questions: > > - how big an effort is it ? Are we talking about weeks, months ? I=20 bet > months. This will > be a hobby project, so it has some chances of failing if it proves=20 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=20 that > correct ? Discussed above. > - I understand I have to modify the emulator to provide a GDB remote=20 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=20 source to > the actual disassembly, > does GDB provide help here ? (that is, when I'm pointing at my=20 assembly > source code line, > I'd like to know to which instruction it corresponds in the 6502=20 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]=20 https://www.embecosm.com/appnotes/ean4/embecosm-howto-rsp-server-ean4-issue= -2.html