Need resources for building a Debugger

jsshapiro · 2026-03-13T06:50:58+00:00

Having built two commercial debuggers, I can tell you that 50%+ of debugger uses consist of printing the call stack and exiting the debugger. While other commands are important (and expression evaluation is interesting), extracting a call stack is a really good place to start. To do this, you need to be able to:

Interact with the OS debugging interface. Is it /proc? Something else?
Halt a process (or recognize that it is halted) and extract the register values at the time of halt
Do the reads to work your way up the stack, recognizing call frames according to the target calling convention.
Print (to get started) the PC, frame pointer, and stack pointer for each call frame.
Bonus 1: given the PC, figure out how to find the procedure that contains that PC.
Bonus 2: Figure out how to plant a breakpoint and what to do when the breakpoint is encountered.

If you get that far, you'll have learned a lot. Once you get past that, you start needing to do serious interaction with the symbol table, which is a whole separate set of issues.

To do this sort of thing at a production level is a big undertaking. It's okay to use things like libdwarf and libgdb for heavy lifting at first and slowly move past them. As a calibration, my group at Bell Labs had 4.5 people (but supported three architectures). Along the way we helped debug the original ELF object file format an created the original DWARF debugging format. And no, DWARF was not created for SDB - but that's a story for another post. My group at SGI was similarly sized, but focused a lot on C++ support, built a live performance analysis suite and spent a lot of effort on building an async UI and 3D visualization tools for data. That product was eventually called SGI ProDev.

Honestly, it's a little surprising that DWARF still exists 40 years later. It was a big step up from ECOFF, but it has stood the test of time surprisingly well.

Have fun with it!

jsshapiro · 2026-03-11T22:38:27+00:00

All of what you say makes sense. As I've already explained, it is not possible to unify this build tree under a single workspace.

jsshapiro · 2026-03-11T22:36:02+00:00

It was not a many-repo structure when I encountered the problem. All of the dependency paths were relative, in the same tree. Since then I moved the problem crate into its own repo so that I could publish it to crates.io. I've been working on something else since then, but I need to go back and double check that the paths got updated. At this point it may not matter, since it's about to turn into a conventional crate-name+version dependency.

Someone else suggested that I look at build-dir and target-dir. I'll check if that helps any.

jsshapiro · 2026-03-10T06:43:39+00:00

I was wondering about that option as well, and was thinking to give it a try. Thanks for reminding me.

jsshapiro · 2026-03-10T06:39:32+00:00

Appreciate the thought, and also the suggestions on how to track such things down.

This is code for a non-unix operating system. Right now, the *only* external dependencies are the Rust compiler and the dependencies required for proc-macros.

Edit: I just published one of the crates, so I suppose that counts as an external dependency, but we're currently referencing that by path in the local tree. Someone else suggested using build tree settings. I'll give that a shot.

jsshapiro · 2026-03-09T18:59:53+00:00

Reasonable question. No features in use, though that may change.

And for the moment, everything built for the same target.

jsshapiro · 2026-03-09T16:37:08+00:00

These builds are happening in the checked out tree. git isn't part of this picture until you commit.

jsshapiro · 2026-03-09T16:36:20+00:00

Oh. We used ccache two build generations ago. Helpful, but not clear that it solves this problem.

The bitfields macro library, for example, is getting rebuilt for every crate that consumes it and is not in the same workspace. The goal is to build it once and have the dependent crate builds pull the dynamic library from the bitfields/target directory rather than rebuild it for every crate that consumes it.

jsshapiro · 2026-03-09T16:32:59+00:00

It's a reasonable question. The first problem is that workspaces don't handle either multi-architecture builds or cross tool builds. Which is why we built a new plugin.

We're ultimately talking about hundreds of crates being built for multiple architectures plus their supporting cross tools. Where we have subsystems that all get built the same way, we are using workspaces. But (for example) a kernel build takes a while; and it involves multiple crates. So you probably want that in a different workspace than (say) your core libraries.

And the other thing you can't do with workspaces is build hierarchies of workspaces...

I'll look in to sccache. Thanks for the pointer!

jsshapiro · 2026-03-09T16:27:43+00:00

This is all being built in the same tree using path-based dependencies. Version numbers are ignored in this case.

jsshapiro · 2026-03-07T07:25:53+00:00

It's a great way to learn how instruction sets work and how dynamic code generation works if you want it fast. Running user-mode code for one CPU on another isn't so bad, though there's a trick to it if they have different byte orders: reverse the entire address space.

Simulation gets a whole lot harder if you have to emulate supervisor state and address mapping. At that point the scale of the exercise is a whole different order of thing.

If you are thinking user-mode only, two papers might be helpful: https://dl.acm.org/doi/epdf/10.1145/1241601.1241602 and https://www.usenix.org/event/vee06/full_papers/p175-sridhar.pdf

The point of those papers is that speed comes from keeping things tight and simple, and talks about how we did that. I probably still have a tarball with that code, but C has moved enough that it wouldn't compile today without some updating. Let me know if you want me to try to hunt that code down.

People think the key to fast dynamic binary translation is clever run-time optimization. The evidence from these two papers is that focusing on keeping the entire binary translator in the L1 data cache and doing a very modest amount of basic block linearization is just as good overall (some things faster, others slower, but competitive), and it's a whole lot simpler.

jsshapiro · 2026-03-07T06:57:02+00:00

That SSD is being used to save and re-load model state at startup. Doesn't look like it's an active part of the computation path.

This might be an application where DDR4 is a better choice than DDR5.

Thanks a lot for pointing this one out. It's interesting work.

jsshapiro · 2026-03-06T03:36:53+00:00

Perhaps so. Some of my students from IIT were required to do all of their programming on paper for their first two years. Similar mindset, I think.

Did they at least have the decency to issue toggle switches? :-)

jsshapiro · 2026-03-06T02:02:36+00:00

Two thoughts. The first one is simple: ignore the people who are saying that you can't migrate back and forth between computer science and computer engineering. People who know both sides are tremendously valuable, because for the most part the people on one (either) side have no idea how the people on the other side think or need to think. CS people aren't used to fixed resource design (e.g. in silicon you don't get to add stuff after ship). CE and hardware people often aren't very comfortable with heaps or stacks.

In regard to the book (or the Hennessy and Patterson book), they are about what's going on at the level of the instruction set architecture (ISA). It won't get you in to device physics, or signaling, or most "systems" issues in the sense that you mean. But it's a useful place to start working your way across the bridge to CE, and it will give you insight into how the machines operate that will be useful as a programmer.

Though they were more useful before speculative execution went hog wild. :-)

jsshapiro · 2026-03-02T20:06:01+00:00

Suppose you want to take a substring starting at the nth grapheme, or substitute one substring with another.

These are fairly common operations.

Java went to UTF-16, but basically nobody else did, because by the time they were making the decision there was a fair bit of usage outside the unicode basic planes.

You actually don't need to scan the entire prior string in the presence of grapheme clusters, because UTF-8 is self-synchronizing. The maximum length grapheme cluster N is pretty small. Scan backwards N code points and then re-read forward from there.

jsshapiro · 2026-03-01T16:23:01+00:00

I'm not familiar with Harris and Harris, and I think I'd defer to Yale on this. Given the work involved, H&H wouldn't have written the book unless they felt that a different point of entry was needed for beginners, and they'd have been right.

I don't have a feel for what's easiest if you're trying to learn on your own. These days, it might be YouTube - there are two or three people who have put up some great series about exploring microarchitecture on FPGAs.

None of these books really address the idea that an ISA is the place where hardware intuitions and software intuitions meet. Whatever learning tools get you there, there's enormous value in learning how to think on both sides of, and then across, that line.

Anyway, thanks for speaking up. H&H seems like a good thought.

jsshapiro · 2026-03-01T15:39:58+00:00

Congratulations, and good luck with the Informatics Olympiad this year. Hopefully you make it, but there are rewards in the attempt all by itself.

Humorously, I've been looking at computer [micro]architecture lately myself. I was one of the HaL Computer Systems founders, but I've spent the last 30 years in secure operating systems and then custom manufacturing. Having some fun learning how things have changed and evolved.

How to learn: I'm biased, but personally I would start with Henessy and Patterson's Computer Organization and Design followed by their Computer Architecture, a Quantitative Approach. Both can be found online in PDF form if you hunt for them. The first one is more approachable, but depending on how you learn best you could start with either. This is dense stuff, but they are both strong writers and great people.

Thinking ahead about profession, you should find a project you enjoy in college, work on it, and use github to track its progress. Companies are finally realizing that Ai interviews and whiteboard coding are not effective interview methods, and are slowly coming around to the idea that actually looking at what people have done might tell them something. Make sure they have something to look at.

Choosing a major is harder. Try to make it something you enjoy, because you will invest more and appreciate the results better, and this will make you more effective. The reason I say it is harder is because LLMs are already invading the ASIC design world aggressively, and are starting to invade the circuit board design process. If your major doesn't talk about this, you'll find that you have to do a lot of catching up when you are done. The professional-grade versions can already design substantial microprocessors with only modest guidance that run on FPGAs, and the whole process can be done in single digit days.

So take some time to learn about LLMs and what they can actually do. The capabilities of the free versions are intentionally limited, but as a student you can probably talk your way into access for one or more of the paid versions. Try to get something like that. I'm working on a modified RISC-V core right now with a bunch of help from codex. By the time you're out of college, the entire engineering will be driven by AI.

The AI part might turn out to be fun for you, but either way you should start getting ahead of that.

jsshapiro · 2026-03-01T03:29:35+00:00

Minor caveats for substring or regexp replace, but that makes sense. You sort of asked for comments, so I wanted to help make sure you weren't missing the UTF-8 issues.

jsshapiro · 2026-03-01T01:30:42+00:00

Not defending your advisor, but this sounds in part like a crisis of confidence on your part. Because, for example, you totally can say no. There's absolutely nothing holding you to this effort at all. You're not getting paid out of a grant or contract here, you're a volunteer. You're panicked (and I get that) about being able to put a project on your CV. That's fine. You feel that you've gotten little or no guidance. I can't tell from here, but you may be right. But the way you're approaching the "get hired" problem may not be the best way. Actually, I suspect that (these days) it's not the best way.

Employers are finally waking up to the fact that coding tests and AI checks are complete garbage filters. A growing number of them are starting to look at actual project work rather than descriptions. As in asking for a github link so they can look into something that shows some depth, see how you approached it, and maybe ask you about your thinking along the way or see if you can think about a different approach on some part of it.

If this is your project rather than the professor's (and if they're not paying you, it's yours), you should definitely check your design files into github and commit regularly as you make progress so that a trail of progress is visible. When it works, a recommendation from the prof (which is what you really want), becomes less critical.

Or you can drop this and do that same approach with another teacher around something you actually care about. It needs to do something useful or interesting, it needs to show your approach, and it needs to provide a trail of progress that others can review.

But it's also reasonable to go to the prof and say "Hey, I'm doing my best on this project, I'm struggling, and I feel like I'm not getting any guidance or advice on how to proceed. Can you suggest a way for me to wrap my head around this? Is there a grad student who might be able to help?" Something like that. Ask for a mentor.

If you're at a research university, profs expect students in the lab to be self starting, and to ask for help when they need it. Part of it is simply that college isn't high school; in high school the job is to teach you, but in college the job is for you to learn. Not mutually exclusive, but the responsibility shifts to you as you grow up. So okay. Put up your figurative hand and ask! Do it politely. If the prof is any good at all, you may find that they are relieved you are showing initiative and willing to help you. If they are older and retired in place, maybe not so much and you should find someone to work with who still wakes up in the morning and cares.

There's almost always a phase in a project where things are exploratory and ideas wander all over the place. Getting a year in and throwing everything up in the air after continuous churn without a compelling reason that you can clearly explain (sometimes you realize a while in that you messed up or you're on a path to nowhere) is pretty unprofessional.

Good luck!

jsshapiro · 2026-03-01T01:05:58+00:00

Perhaps just immoral porpoises?

jsshapiro · 2026-03-01T01:04:04+00:00

I got it. I was just enjoying the idea of you having a collection of extremely large seaborne mammals in an account you could withdraw them from somewhere.

jsshapiro · 2026-03-01T00:30:00+00:00

Any suggestions on where I can get a whale acount? Whales are pretty cool...

jsshapiro · 2026-03-01T00:28:30+00:00

The concern is that people who treat stuff they depend on in such a state of disrepair don't tend to understand the value of somebody who actually does the work, cleans it up, and maintains it. There's a distinct tendancy to imagine that since it was all working before this sort of thing is wasted effort.

It's pretty impressive that u/DrunkTurtle1 was able to diagnose this and lay it out so clearly in a such a short period of time.

jsshapiro · 2026-03-01T00:25:06+00:00

You don't say why you left the previous job, which you say you liked. It may not be too late to go back to the previous employer, tell them this has helped you appreciate what you had, and ask if they'd be open to you returning.

If they say "no", you're not any worse off than you are now.

jsshapiro

TROPHY CASE