Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
I have call stack backtrace, register dumps, object file symbol lookup, and lastly i now want disassembly / code readability.
While considering implementing it for my self for about 1 second, i realised it would take a fair amount of time and i decided to look for some free/easy stuff online.
I found libdisasm. In its first release it was very small an nice. I think i might use that.
What have you used for your internal code disassembler?
I've implemented my own (basic instructions, and a few fpu, 3dnow, sse, sse2). First I used openbsd's source (http://www.openbsd.org/cgi-bin/cvsweb/s ... xt%2Fplain) and rewrote it in assembly, but I found it too big (~60k if I remember well), so I optimized it. Now the full disassembler is ~12k (including instruction tables).
If you want to learn, I suggest to do the same: get a fairly small C source as a guide, understand it and implement it in your crash handler.
I have a disassembly engine in 3078 bytes, currently supporting all standard IA-32 instructions (but no MMX, SSE, VMX etc yet). I plan to redesign it at some point to allow the use of symbolic debugging information.
Gigasoft wrote:I have a disassembly engine in 3078 bytes, currently supporting all standard IA-32 instructions (but no MMX, SSE, VMX etc yet). I plan to redesign it at some point to allow the use of symbolic debugging information.
Wow, 3k! That's something! Are you planning to implement 64 bit intructions?
I too recently implemented a disassembler for the debugging system I'm working on. It disassembles 1-byte and some 2-byte opcode instructions (I just implemented the ones I see while debugging).
Here is a little pic, it includes some symbol information at every breakpoint (function + offset) and on jmp/call instructions. I did it in about half a week and it delayed because of some bugs I found on the way.
It really does not take too much time and I hope you can do it in a couple of days.
I wrote mine myself many years ago. It supports all kinds of instructions, including 16 and 32 bit operands and code segments. It also translates call-gates to their function names, and it contains an interactive process that can single-step kernel and usermode code. It is 28k. It also has an ethernet IPC setup for debugging video-mode code and similar.
Regarding crash-dumping, I've not found it useful to disassemble instructions there, especially since real crashes only occurs when something goes really bad, and often CS:EIP is not even pointing to anything valid. Simple faults in kernel are not considered crashes, but rather invoke the above kernel-debugger interface. Although, I'm working on a more advanced crash-setup as well, especially aimed at SMP-crashes (as I wrote in another thread), and this will also be an interactive interface that is core-based rather than thread-based as the kernel-debugger is.
As for source-level debugging the kernel, this is something I'm partly done with. The current port of OpenWatcom's debugger allows tracing syscalls into kernel mode from an usermode application. This does occur at a symbolic level, but since all drivers are still assembly, there is not a great advantage of this (yet). However, as I get the OpenWatcom compiler to generate 32-bit device-drivers from C/C++ code, this will become an interesting feature.
It is actually easier if the code is not your own. You get to prove other people made mistakes, which is easier on the ego. Once you get over that and start taking pride in the improvement rather than the buglessness-from-the-start, the toon I linked above describes it pretty well.
Every good solution is obvious once you've found it.
Regarding crash-dumping, I've not found it useful to disassemble instructions there, especially since real crashes only occurs when something goes really bad, and often CS:EIP is not even pointing to anything valid
Not always true, good number of crashes happen when OS itself bugchecks ! . Or when you have to force a crash when lot of applications hang. In a good number of cases CS:EIP does point to a valid address. ( I have seen only itanium crashes not x86 ).
It is actually easier if the code is not your own
Not really, It takes that much more time to read and understand what the original code is intended to do ! .
If you wrote your own code, you either know the location of the bug in an instant, or you tend to skip the wrong "unlikely" stuff, which isn't often the case for other people's code. In work, I've spent more time fixing my own bugs compared to fixing other people's bugs.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
Regarding crash-dumping, I've not found it useful to disassemble instructions there, especially since real crashes only occurs when something goes really bad, and often CS:EIP is not even pointing to anything valid
Not always true, good number of crashes happen when OS itself bugchecks ! . Or when you have to force a crash when lot of applications hang. In a good number of cases CS:EIP does point to a valid address. ( I have seen only itanium crashes not x86 ).
I should have made another argument. The big risk-factor in a fatal, scheduler / interrupt-related crash is that memory/selectors/page-tables are invalid, and thus that the crash-handler itself blows-up when memory for instructions are accessed (which creates crash-loops so you have no idea what came first). Especially when it is run in the context of a core that is part of the crash.
Combuster: I've read in the morning at my office that you quote me by mistake. I wanted to reply, but now that I'm at home, the message is gone, so I wrote it here: sorry for the misunderstanding! Now that I know you quoted the wrong post, everything you wrote make sense! And I'd take a look at your OS, nice work indeed!
I just reused the disassembler in the kernel debugger, so now I also have disassembly in the crash debugger/monitor.
I solved the issue of reading memory by emulating the whole process of paging and segmentation from the ground-up by starting from the linear address/size of the GDTR and CR3 saved in the core in question. This code should never fault, almost regardless of what the core has done.
