timmisiak

5 ms·

1.
by timmisiak 2y ago
I suspect the biggest issue is that courses like to talk about how instructions are encoded, and that can be difficult with x86 considering how complex the encoding scheme is. Personally, I don't think x86 is all that bad as long as yo
2.
by timmisiak 2y ago
Glad you like it. I used m10c, with a few tweaks: https://github.com/vaga/hugo-theme-m10c
3.
by timmisiak 2y ago
I think both are useful, but designing a modern CPU from the gate level is out of reach for most folks, and I think there's a big gap between the sorts of CPUs we designed in college and the sort that run real code. I think creating an
4.
by timmisiak 3y ago
Honestly it's a great exercise for learning how low level stuff works in general. Happy to answer any questions you have!
5.
by timmisiak 3y ago
Yes, software breakpoints are difficult to get correct (the main reason why I started with hardware breakpoints). It gets more complicated with kernel debugging, where a single step (trap flag) could get pre-empted by an interrupt handler.
6.
by timmisiak 3y ago
Absolutely, rust sitter is fantastic. I haven't used any other parsers in Rust so I don't have much of a comparison point, but it's probably hard to get much more clear and concise, which I think really helps.
7.
by timmisiak 3y ago
I think my record when I was on the WinDbg team was 5 debuggers deep. I honestly think one of the best parts of writing a debugger is being your own recursive customer. I think that's something you only get to do for a few things. Debu
8.
by timmisiak 4y ago
I worked on the one that ships with WinDbg: https://learn.microsoft.com/en-us/windows-hardware/drivers/d... Literally every person who uses it for debugging a hard problem absolutely raves about it. Debugging
9.
by timmisiak 4y ago
Apologies. I'm just using a Hugo template and haven't spent a lot of time figuring out how to customize it. You're right though, the contrast isn't great.
10.
by timmisiak 4y ago
Yes, that's exactly what I did. Most useful thing I did was setting up a unit test framework to test a single instruction, and then generating a huge number of variations of those instructions.
11.
by timmisiak 4y ago
I talked a bit about the Intel SDM in the last post I wrote (linked at the top). The SDM is great for getting the specific details, but isn't always approachable for high level overview things.
12.
by timmisiak 4y ago
TTD (the WinDbg one) works very well for complex multithreaded apps. (The caveat being the performance hit you get from emulation). It's one of the big advantages it has over rr. The main use case I saw for TTD was debugging complex me
13.
by timmisiak 4y ago
Yes, saving and restoring flags is very expensive. I thought about talking about that in the article but figured that was too much of a detour. Darek Mihocka wrote a really interesting article about how to optimize flag calculations in an x
14.
by timmisiak 4y ago
My point is the smaller encoding is what gives you the performance benefit. When done across an entire function/module, you can get a measurable increase in hit rate for the instruction cache. Not that the instruction itself is faster.
15.
by timmisiak 4y ago
Yes, that made it 100x easier, because I was able to write unit tests that literally did a single step over the instruction and compare the register context to the emulated register context. The single step approach didn't work for all
16.
by timmisiak 4y ago
That's really interesting. I had no idea there were structurally valid instructions that are longer than 15 bytes.
17.
by timmisiak 4y ago
Funny enough, we tried going down the road of doing a JIT, but for our use cases pure emulation was often fast enough and it wasn't worth the extra complexity to do JIT. Part of that is probably due to the architecture of how TTD works
18.
by timmisiak 4y ago
That's true. It's far too broad to learn everything without having a specific goal in mind. Learning the parts of asm that are useful for writing asm code is very different than learning enough asm to understand what APIs are be
19.
by timmisiak 4y ago
Covering how to practically use it is far too much for a single post (and I don't think I really claimed to teach assembly... I just want to give people the tools they need to start learning assembly). This was mainly to get people t
20.
by timmisiak 4y ago
The target audience here were folks that have very little experience with asm, but you're completely right that a lot of complexity gets glossed over. That's not even to mention cases where an instruction behaves differently depen
21.
by timmisiak 4y ago
That's actually something I want to tackle in the next post I'm writing. I need good examples though of stuff like that, so I think I need to spend some time with godbolt...
22.
by timmisiak 4y ago
I'm planning to write a future post on "common compiler generated code" to recognize those patterns. The intention of this post was to encourage folks who think asm is scary to give it a try because it's not as bad as th
23.
by timmisiak 9y ago
Oh OK, that makes sense then. Yeah, that's been fixed in current internal builds and will go out on the store soon.
24.
by timmisiak 9y ago
Yup, you got it. Not just jumping back and forward, but seeking to points in time when memory changed. For instance... have some memory that got corrupted? With normal debugging you're probably out of luck unless you get some hints as
25.
by timmisiak 9y ago
FYI, Microsoft TTD is supported on AMD CPUs.
26.
by timmisiak 9y ago
Right now you can attach TTD to a process after initialization (or any point in time prior to the repro), but you can't trace starting from a breakpoint. We'd love to add that functionality though, so I'm sure you'll see
27.
by timmisiak 9y ago
What duplicate lines are you talking about? The debugger isn't written from scratch, just the UI. All of the underlying functionality is essentially the same, just in a more usable shell, and if you collapse the ribbon and retheme the
28.
by timmisiak 9y ago
The underlying engine is the same, so all of the functionality is fundamentally the same.
29.
by timmisiak 9y ago
I believe all of those projects are based on single-core debugging. Restricting the trace to a single core is one way of introducing determinism in the process as a way of allowing replay later. Microsoft time travel debugging is a multi-co
30.
by timmisiak 9y ago
The overhead varies depending on how cpu/IO bound the application is. IO isn't really affected, so IO bound applications tend to not see a big slowdown. In theory, you could see a very large slowdown in the worst case, but in the

More ›