OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 11:00 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 13 posts ] 
Author Message
 Post subject: Disassembly in internal crash debugger
PostPosted: Sat Feb 27, 2010 5:16 am 
Offline
Member
Member
User avatar

Joined: Sat Jul 07, 2007 7:49 pm
Posts: 131
Hi,

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?

Attachment:
gpf_bsod.PNG
gpf_bsod.PNG [ 13.7 KiB | Viewed 6848 times ]


-
Thomas


Top
 Profile  
 
 Post subject: Re: Disassembly in internal crash debugger
PostPosted: Tue Feb 08, 2011 3:28 pm 
Offline
Member
Member
User avatar

Joined: Tue Feb 08, 2011 1:58 pm
Posts: 496
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.


Attachments:
scr2.png
scr2.png [ 31.03 KiB | Viewed 6660 times ]
scr1.png
scr1.png [ 31.4 KiB | Viewed 6660 times ]
Top
 Profile  
 
 Post subject: Re: Disassembly in internal crash debugger
PostPosted: Tue Feb 08, 2011 5:36 pm 
Offline
Member
Member

Joined: Sat Nov 21, 2009 5:11 pm
Posts: 852
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.

Sample output:
Code:
00401000 mov esi,00401000
00401005 mov edi,00404010
0040100a mov edx,esi
0040100c push edi
0040100d call 00401084
00401012 mov al,20
00401014 stosb
00401015 push edi
00401016 push esi
00401017 mov ebp,00404000
0040101c mov dword ptr [ebp+04],0040103d
00401023 mov [ebp+08],esp
00401026 mov ebx,00000303
0040102b mov cl,05
0040102d push edi
0040102e call 004023bf
00401033 pop edi
00401034 call 0040228a
00401039 pop eax
0040103a pop eax
0040103b jmp 00401046
0040103d pop esi
0040103e pop edi
0040103f inc esi
00401040 mov eax,003f3f3f
00401045 stosd
00401046 mov al,00
00401048 stosb
00401049 pop ecx
0040104a push ecx
0040104b mov al,[ecx]
0040104d sub al,41
0040104f cmp al,1a
00401051 jae 00401056
00401053 add byte ptr [ecx],20
00401056 inc ecx
00401057 cmp ecx,edi
00401059 jb 0040104b
0040105b call dword ptr [00403000]
00401061 pop edi
00401062 cmp esi,004010b0
00401068 jb 00401005
0040106a ret
0040106b push ecx
0040106c push ecx
0040106d shl cl,02
00401070 ror edx,cl
00401072 jmp 00401087
00401074 push ecx
00401075 push +02
00401077 shl edx,18
0040107a jmp 00401087
0040107c push ecx
0040107d push +04
0040107f shl edx,10
00401082 jmp 00401087
00401084 push ecx
00401085 push +08
00401087 pop ecx
00401088 push eax
00401089 rol edx,04
0040108c mov al,dl
0040108e and al,0f
00401090 daa
00401091 cmp al,10
00401093 sbb al,cf
00401095 stosb
00401096 loop 00401089
00401098 pop eax
00401099 pop ecx
0040109a ret
0040109b rep movsb
0040109d clc
0040109e ret
0040109f fld real10 ptr [esp+ebx*8-14]
004010a3 fdivr real4 ptr [0000fedc]
004010a9 fcom real8 ptr gs:[12345678]


Top
 Profile  
 
 Post subject: Re: Disassembly in internal crash debugger
PostPosted: Wed Feb 09, 2011 12:39 pm 
Offline
Member
Member
User avatar

Joined: Tue Feb 08, 2011 1:58 pm
Posts: 496
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?


Top
 Profile  
 
 Post subject: Re: Disassembly in internal crash debugger
PostPosted: Thu Feb 10, 2011 9:01 pm 
Offline

Joined: Thu Jan 27, 2011 8:17 am
Posts: 11
Location: Colombia
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.
Image


Top
 Profile  
 
 Post subject: Re: Disassembly in internal crash debugger
PostPosted: Fri Feb 11, 2011 1:35 am 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 3191
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.


Top
 Profile  
 
 Post subject: Re: Disassembly in internal crash debugger
PostPosted: Fri Feb 11, 2011 2:26 am 
Offline
Member
Member
User avatar

Joined: Mon Jan 26, 2009 2:48 am
Posts: 792
This is great. We all acknowledge the importance of debugging, but almost no one is enjoying it, and you guys are writing disassemblers for fun! =D>

I hate debugging. Really, I do.


Top
 Profile  
 
 Post subject: Re: Disassembly in internal crash debugger
PostPosted: Fri Feb 11, 2011 2:56 am 
Offline
Member
Member
User avatar

Joined: Thu Nov 16, 2006 12:01 pm
Posts: 7612
Location: Germany
Debugging is a state of mind.

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.


Top
 Profile  
 
 Post subject: Re: Disassembly in internal crash debugger
PostPosted: Fri Feb 11, 2011 5:15 am 
Offline
Member
Member
User avatar

Joined: Thu Jun 04, 2009 11:12 pm
Posts: 281
Hi,
Quote:
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 ).

Quote:
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 ! .

--Thomas


Top
 Profile  
 
 Post subject: Re: Disassembly in internal crash debugger
PostPosted: Fri Feb 11, 2011 5:23 am 
Offline
Member
Member
User avatar

Joined: Wed Oct 18, 2006 3:45 am
Posts: 9301
Location: On the balcony, where I can actually keep 1½m distance
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 ]


Top
 Profile  
 
 Post subject: Re: Disassembly in internal crash debugger
PostPosted: Mon Feb 14, 2011 12:56 pm 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 3191
Thomas wrote:
Hi,
Quote:
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.


Top
 Profile  
 
 Post subject: Re: Disassembly in internal crash debugger
PostPosted: Mon Feb 14, 2011 2:21 pm 
Offline
Member
Member
User avatar

Joined: Tue Feb 08, 2011 1:58 pm
Posts: 496
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!


Top
 Profile  
 
 Post subject: Re: Disassembly in internal crash debugger
PostPosted: Tue Feb 15, 2011 2:30 pm 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 3191
I just reused the disassembler in the kernel debugger, so now I also have disassembly in the crash debugger/monitor. :D

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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot], Garnek0, Google [Bot], Yahoo [Bot] and 59 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group