Hacker News new | past | comments | ask | show | jobs | submit login

My god, the ability to use this for tracing code makes me more excited than anything I've seen in a while. The debugging facilities on x86 are, well, limited to the point of being damn near useless. I may spend some time hacking solid trace functionality into this, if it ends up being an open core.



There are already several open x86 cores. You're not likely to find these as useful for modern code though, since most people are finally using x86_64 these days and a lot of the instructions being used (and a lot of the processor characteristics of modern chips, from SMT to the trace cache) are very different in modern Intel chips.

You might try instrumenting bochs, which might both run your code faster, require less hardware and give you more accurate results. In many ways, bochs is much better built for the type of thing you want.


I like the project, but for tracing code, you could probably do better with Bochs. Bochs lets you set breakpoints at certain addresses and CPU states, for example.

If bochs doesn't do enough, it would probably be easier to hack it up to do what you need.


For such purposes, binary instrumentation is probably a more proper tool. Various options out there, I personally prefer Pin [1] because it's extremely robust and gives you good control of the overheads from instrumenting.

edit: grammar

[1] http://software.intel.com/en-us/articles/pin-a-dynamic-binar...


For an undergrad OS course, we had to build an OS from scratch. Part of that was doing the dance to get from real mode to protected mode. We had a bug in our boot loader that we were pretty stumped with; to solve it, we ended up hacking debugging printfs into the "CPU" inside QEMU and found the problem very quickly.

I don't want to be working at that level every day but it sure was a fun project.


I remember dumping registers to text-mode screen memory so that I wouldn't waste a register. Half of the result landed in the color values, so sometimes I couldn't read all of the value because it was flashing green on green. I prefered Bochs' Port E9 hack.

Oh, OS courses at the university... good old time. (Some participants complained that going from zero to bare-metal x86 was too difficult.)


So in my day to day job I'm actually a component design engineer working mostly on design validation at a company that's "involved" in x86 development. I'm sort of curious, what debugging features are you hoping for or what's missing that's negatively impacting your workflow?

Honestly, when I'm debugging hardware where I have the high level specifications, the microarchitecture spec and the system verilog files that implemented the design it's still kind of a pain to trace things.

The other downside of having all the signals is that little things can be unintentionally misleading. As an example I was working with coworker trying to trace a memory transaction through some complicated logic blocks and there was a point we originally missed where the bottom few bits of an address aren't necessary for the hardware. Later after this point the bottom bits were reused to communicate transaction properties along with the significant address bits. There was a bit of confusion about why we were reading a "bad address" before we realized what happened.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: