Conversation

Notices

1. Embed this notice
   ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Wednesday, 07-May-2025 03:39:06 JST ✧✦Catherine✦✧

   there's nothing quite so satisfying as seeing source level debugging for the first time with a JTAG probe you designed

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Wednesday, 07-May-2025 03:45:01 JST ✧✦Catherine✦✧

     in reply to

     • Andrew Zonenberg

     @azonenberg well, at least you knew who to blame for this!

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Wednesday, 07-May-2025 03:45:02 JST Andrew Zonenberg

     in reply to

     @whitequark Better than the debug hell I went through in my thesis work.

     I was using a gdbserver I wrote to debug firmware I wrote, compiled against a libc I wrote, running on a CPU I wrote, hooked up to an interconnect I wrote, on a board I designed, using a FTDI-based debug dongle I designed.

     And something was going wrong somewhere in the stack and the firmware was locking up (not a full deadlock, instructions were still executing, but it was stuck in a polling loop or something and not making any forward progress). I trusted nothing and had no idea where in the stack things were going wrong.

     And it was on a very full xc6slx25 that had enough spare gates to fit *either* JTAG debug support on the CPU *or* a homebrew ILA to sniff a few internal signals. But not both.

   • Embed this notice
     poleguy (poleguy@mastodon.social)'s status on Wednesday, 07-May-2025 04:07:20 JST poleguy

     in reply to

     @whitequark I'm not confident I know exactly which pieces you've been working on here. But I have dreamed to do something like this for a custom DSP inside an FPGA at work. I'm not afraid of getting my hands dirty. But the last time I tried to find the "hello-world tutorial" for connecting gdb to an arbitrary device I didn't get very far. I'd love to connect it via our existing cli/debug interface (serial-usb). I've implemented everything needed to do step debugging in the hdl, but no gdb yet.

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Wednesday, 07-May-2025 04:13:26 JST ✧✦Catherine✦✧

     in reply to

     • poleguy

     @poleguy well, that's because there isn't one

     do you even have gdb for your DSP target?

   • Embed this notice
     poleguy (poleguy@mastodon.social)'s status on Wednesday, 07-May-2025 04:51:40 JST poleguy

     in reply to

     @whitequark You mean there isn't a hello world? If so, that makes me feel good that I didn't just fail to find it. :-)

     I probably don't have the terminology right. What does it mean to "have gdb" for my "DSP target"?

     I presume the steps look something like write some code on the PC that translates between what gdb needs to work and what my serial-cli can provide. (?!).

     This is a custom FPGA, I presume there is also some sort of definition for my architecture/assembly/machine code needed?

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Wednesday, 07-May-2025 04:55:43 JST ✧✦Catherine✦✧

     in reply to

     • poleguy

     @poleguy for starters, you need to write a disassembler for gdb and an object file handler for binutils, if you don't use ELF

     then you need to emit DWARF debug info in your compiler (assuming you compile from an HLL like C)

     this is loads of very tedious and thankless work

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Wednesday, 07-May-2025 04:56:13 JST ✧✦Catherine✦✧

     in reply to

     • poleguy

     @poleguy the serial interface is the really easy part in comparison

   • Embed this notice
     poleguy (poleguy@mastodon.social)'s status on Wednesday, 07-May-2025 05:07:29 JST poleguy

     in reply to

     @whitequark This does not surprise me. But in my previous attempt I could not find even a basic list of steps like this.

     I can disassemble/write the machine code. But I don't know how to do so "for gdb".

     We do not use elf. The code is just a binary file with machine code that gets loaded into an FPGA RAM.

     We have not written a compiler. Everything is written in assembly. I would aim for assembly level debug only. I wonder if this makes it easier or harder.

     Tedious/thankless sounds right.

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Wednesday, 07-May-2025 05:14:50 JST ✧✦Catherine✦✧

     in reply to

     • poleguy

     @poleguy I would strongly suggest doing your own, perhaps simplistic, debugger instead of trying to make GDB work for you. you will be so much less miserable, and learn almost the same amount if not more

   • Embed this notice
     poleguy (poleguy@mastodon.social)'s status on Wednesday, 07-May-2025 06:31:47 JST poleguy

     in reply to

     @whitequark done.

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Wednesday, 07-May-2025 06:32:42 JST ✧✦Catherine✦✧

     in reply to

     • poleguy

     @poleguy already implemented? nice :D

   • Embed this notice
     poleguy (poleguy@mastodon.social)'s status on Wednesday, 07-May-2025 10:36:47 JST poleguy

     in reply to

     @whitequark yes. I implemented a step debugger, breakpoints and memory inspection when we designed the processor originally. In reality the code is all real time dsp, so debugging is mostly done in rtl/cocotb sim where we just spit out a trace file based on watching a variable and/or program counter. Or we do it in hardware using telemetry over a gigabit serial link where we can stream out whatever state we need to monitor. Or we use one channel of the audio output to monitor an internal node.

   • Embed this notice
     poleguy (poleguy@mastodon.social)'s status on Wednesday, 07-May-2025 11:01:09 JST poleguy

     in reply to

     @whitequark I feel a bit sad that gdb is seemingly ossified so hard that spinning up a new architecture/ language/ machine code is essentially harder than reinventing everything from scratch. But if someone like you won't even endorse it, it is not worth pursuing even as a personal challenge. My youthful idealism is dashed. :-(

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Wednesday, 07-May-2025 11:01:09 JST ✧✦Catherine✦✧

     in reply to

     • poleguy

     @poleguy yeah. I'm unaware of any nice to use retargetable debugging framework; "real" toolchains like GDB and LLDB require a massive amount of ceremony (LLDB's is more structured but not necessarily nicer to use per se), and other tools tend to be very x86/AArch64 specific

   • Embed this notice
     poleguy (poleguy@mastodon.social)'s status on Wednesday, 07-May-2025 11:09:56 JST poleguy

     in reply to

     @whitequark "ceremony..." that resonates. Well, I appreciate you humoring my line of inquisition as far as we took it. It reaffirmed my sense that it was not a route likely to pay off with any practical value.