flat assembler
Message board for the users of flat assembler.

Index > Projects and Ideas > FDBG - win64 Linux64 UEFI x64 AMD64 debugger

Goto page Previous  1, 2, 3, 4, 5 ... 9, 10, 11  Next
Author
Thread Post new topic Reply to topic
Garthower



Joined: 21 Apr 2006
Posts: 158
Location: Ukraine
Garthower
rugxulo wrote:
Cannot QEMU and/or BOCHS emulate 64-bit? (Sorry, never tried to do so, but that's what I hear ...).


VMWare 5.xx or higher can emulate x64-86 on 32-bit platform. More detailed information can be found on a site of the manufacturer http://www.vmware.com/
Post 24 Feb 2007, 09:44
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
Hmm, I've been testing all my apps under QEMU for months now - from the very first version of MenuetOS IIRC. The sad thing is that QEMU is only 32-bit itself so 64-bit emulation is wacky, but lets hope they move to 64-bit native so they don't HAVE to emulate 64-bit under 32, but rather just pass 64-bit requests to 64-bit processor Wink
Post 27 Feb 2007, 13:19
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
Garthower



Joined: 21 Apr 2006
Posts: 158
Location: Ukraine
Garthower
2Feryno: Do you can to add display of abnormal float numbers (negative infinity etc.) in a window of FPU/MMX data more corect?
[edit]Remove url to screenshot[/edit]


Last edited by Garthower on 20 Mar 2007, 16:43; edited 1 time in total
Post 02 Mar 2007, 17:19
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen
Would it be possible to add the address of the access violation to the fdbg's message?
Quote:
Exception. ProcessId=0000034Ch ThreadId=000000D0h Address=0000000000401005h ExceptionCode=C0000005h=EXCEPTION_ACCESS_VIOLATION first_chance

Something like
Quote:
...ExceptionCode=C0000005h=EXCEPTION_ACCESS_VIOLATION At Address=8000000000000000h
Post 19 Mar 2007, 11:32
View user's profile Send private message Visit poster's website Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 457
Location: Czech republic, Slovak republic
Feryno
2 MazeGen, thank, I'll add it there.
After exception, Code 1st window is updated so you can see something after disassembled instruction - something between brackets -which is the address and then ? follows so it looks like [...address...]=? which means that fdbg failed to read memory at that address - but I'll add the address into the Log window too

2 Garthower - thank for idea, I was thinking about rewriting of the routines for displaying floating numbers in the time of your post. In fact of FPU instruction pointer and FPU data pointer method of detecting single steps in debugger I was made to rewrite these routines without usage of FPU instructions. I was thinking about one week long how to do it efficiently enough and finaly I got an idea which wastes 0,5 MB of memory but is quite accurate and perhaps fast enough too. If somebody is interested in FPU antidebugs then I'll post here more details.
It would be kind to test these new routines for displaying floating registers (st, mm, xmm) more thoroughly than my several minutes of limited testing...

edit from 2007 March 26: deleted attachment (quota limit)


Last edited by Feryno on 26 Mar 2007, 13:25; edited 1 time in total
Post 19 Mar 2007, 14:51
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Garthower



Joined: 21 Apr 2006
Posts: 158
Location: Ukraine
Garthower
I shall test work with floatint point numbers the nearest months very densely since now I develop the math-based RTL. At occurrence of new problems I shall inform certainly.
Post 20 Mar 2007, 16:55
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 457
Location: Czech republic, Slovak republic
Feryno
Floating point numbers are calculated with precision higher than necessary for any floating point numbers calculations, but they were simply truncated in previous version. Because Garthower is going to test floating numbers heavily, I added rounding for them. It's nicer to see e.g. 1.2000000 instead of 1.1999999 which was truncated 1.19999996301...


Description: windows x64 debugger
Download
Filename: fdbg0012.zip
Filesize: 309.32 KB
Downloaded: 374 Time(s)

Description: samples and antidebugs, the same as in previous version
Download
Filename: fdbg0010_samples.zip
Filesize: 116.4 KB
Downloaded: 338 Time(s)

Post 26 Mar 2007, 13:09
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Garthower



Joined: 21 Apr 2006
Posts: 158
Location: Ukraine
Garthower
Hmmmm.... This rounding off is not absolutely exact with real values as I have understood? Can do is better roundings off how the program which is now debugged, it is established in corresponding operating registers? And that suddenly in the future because of it surprises will get out...
Post 01 Apr 2007, 11:04
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 457
Location: Czech republic, Slovak republic
Feryno
Every floating point number is calculated to more than 40 decimal digits by fdbg and it requires rounding at the end to fit into 18 digits for 80-bit FPU numbers, 16 digits for double precision, 8 digits for single precision.
In the feature it should be easily extended to show more digits of floating.
Most of floatings can't be stored absolutely accurate e.g. single precision 1.0e-40 could be e.g. 9.99999996512e-41 etc.
Rounding feature from ver. 0012 handles only these cases and doesn't decrease accuracy. You should allways keep in mind that there is something after the last shown digit of floating but it doesn't alter accuracy too much.

Thank to DLL produced by r22 I discovered a bug which happens only under Vista (not under older win versions) - fixed in ver 0013

deleted attachment, released new version


Last edited by Feryno on 13 Apr 2007, 07:59; edited 1 time in total
Post 02 Apr 2007, 12:46
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Garthower



Joined: 21 Apr 2006
Posts: 158
Location: Ukraine
Garthower
Hi Feryno!

I have a problem with FDBG. FDBG crashes at debugging this source code on command "xor rax,rax" (!!!)

Code:
format PE64 GUI
entry start

include 'C:\fasm\INCLUDE\MACRO\PROC64.INC'
include 'C:\fasm\INCLUDE\MACRO\IMPORT64.INC'

section '.code' code readable executable

start:
       push    rbp
 xor     rax,rax
     mov     qword [rax],0
       invoke  ExitProcess,0

;==============================================================================

section '.idata' import data readable writeable

library kernel32,'KERNEL32.DLL'

import    kernel32,\
 ExitProcess,'ExitProcess'
    


with execption:
code=C0000005
addr=10000A484
rax=0
rbx=8
rcx=FF4
rdx=C0000018
rsp=225F3C0
rsi=0
rdi=225F3D0
r8=B
r9=77EC0000
r10=81
r11=206
r12=0
r13=0
r14=0
r15=0

Maybe, it's connected by that I have install today SP2?
Post 11 Apr 2007, 01:36
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
Tommy



Joined: 17 Jun 2003
Posts: 489
Location: Norway
Tommy
mov qword [rax],0 -> mov qword [0],0
exception code C0000005 = access violation

so i don't find it strange that the program itself crashes, but does fdbg crash and close as well?
Post 11 Apr 2007, 06:33
View user's profile Send private message Visit poster's website Reply with quote
Garthower



Joined: 21 Apr 2006
Posts: 158
Location: Ukraine
Garthower
Yes, if to delete a command "mov qword ptr [rax],0", all works. But if it to return on a place, at me FDBG0013 crash itself before the command.
Post 11 Apr 2007, 11:56
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 457
Location: Czech republic, Slovak republic
Feryno
yeah, thank guys, it was serious bug when accessing unreachable memory
I tried to fix something to work under Vista in ver 0013 and I made another bug...
here fixed and stable version 0014
As Tommy wrote, debugger mustn't crash anytime.
If program being debugged (=debuggee) makes a bug, debugger must catch the buggy instruction and stay running. Debugger itself must be bug-free. Program being debugged (=debuggee) may contain bugs and debugger is responsible to discover them.


Description: fdbg ver 0014 for windows x64
Download
Filename: fdbg0014.zip
Filesize: 310.1 KB
Downloaded: 375 Time(s)

Description: debuggee samples and antidebugs for windows
Download
Filename: fdbg0010_samples.zip
Filesize: 116.4 KB
Downloaded: 326 Time(s)

Post 13 Apr 2007, 08:06
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Garthower



Joined: 21 Apr 2006
Posts: 158
Location: Ukraine
Garthower
Now it's stable. Thanks Feryno for operative reaction to a problems!
Post 13 Apr 2007, 08:56
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
Quantum



Joined: 24 Jun 2005
Posts: 122
Quantum
Garthower wrote:
VMWare 5.xx or higher can emulate x64-86 on 32-bit platform.

VMware Workstation 5.5.x:
Quote:
If your host machine has a 32-bit processor or a 64-bit processor that is not supported, Workstation does not support 64-bit guest operating systems.

And that's logical, because VMware doesn't emulate a processor - it uses virtualization over a real processor and a regular x86 can't appear as an enhanced x86-64.

Bosch does support x86-64 over a regular x86. Apparently, so does QEMU, but I had troubles using it so far.
Post 13 Apr 2007, 15:44
View user's profile Send private message Reply with quote
mattst88



Joined: 12 May 2006
Posts: 260
Location: South Carolina
mattst88
Are you no longer making a Linux64 version?
Post 17 Apr 2007, 19:34
View user's profile Send private message Visit poster's website Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 457
Location: Czech republic, Slovak republic
Feryno
Linux version -
Perhaps new routines for parsing commands - at present time, commands are too much sensitive to improper parameters - e.g. if you type 2 spaces instead of 1 the whole command fails, this is the same scenario when you accidentally press CapsLock etc.
Perhaps creating multiprocess/multithread support (currently it handles only 1 process)?
Now I remember, I had really great idea, but it required completelly rearrangment of swithing to procedures of handling commands - the idea was: you can set what to do after every step - something like .gdbinit file
e.g. display 8 instructions, then xmm1-3 register etc. after every step - then you wouldn't need to type the same command every step.
And now I remember another idea - command line buffer holding old commands so you can press up/down arrow instead of typing long commands again.
But all this ideas require a lot of time which I currently don't have.
Post 18 Apr 2007, 05:32
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
Hi, I've got this picture for you: http://www.tud.ttu.ee/~t060429/Up/Optimal.png (@1400x1050 res.)
Have you got any more optimal solutions for arranging sections?
One bad thing with this arrangement is that the Flags and Seg windows
are still too wide and Windows won't let me resize them any smaller Sad

Btw, one small request:
-that under the Help menu > there could be About dialog with "Authoring message" and FDBG version.

Thank you!
Post 11 May 2007, 07:14
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 457
Location: Czech republic, Slovak republic
Feryno
Hello, Madis731

big guru on 64-bit asm with the nick r22 used to have screen resolution even 800x600
fdbg has a lot of MDI child windows, but usually only few of them are really necessary and most of them may be iconized to prevent overfilling your screen.
There is one strange fact - it is explained in the included help file - that there are more code and data windows...
The fact of 2 code windows doesn't mean 2-core CPU... Brief explanation - I used to debug with turbo debugger which had only 1 code window. When I needed to follow subprocedure (call) in code window then I lost the code at the instruction pointer so at the end I had to go back manually. So I thought that 2 code windows may help to somebody who needs it, others can simply iconize code 2nd windows to save a part of screen. Code 1st win keeps updated to RIP and code 2nd may be used for walking through other parts of code. This is the same with 3 data windows. For repz movsb it is good choice to have 2 extra data windows, and the first one is good for not to loosing the view into previous part of data. Usually, you need only 1 code, 1 data, 1 stack, 1 GPR, 1 RIP, 1 Flags, 1 XMM, 1 MM/ST and this configuration fits into 1024*768 screen resolution. If you need really big code window, you can stretch it up to 64 "lines" (ListView items = instructions) but then it occupies the most of your screen.

Seg windows are allmost completelly useless in ring 3 long mode (only 64-bit GS register seems to be usefull in some rare cases under 64-bit ms windows). Seg window is shown there only because of the existence of segment registers in long mode...
Windows doesn't let you to resize Flags and Segment registers windows because there is low limit of MDI child window size in OS.

Version of fdbg - this is the first and only one line in Log window when you run fdbg. The number there is strange (but logical) and it increases in every new version, it has the format yyyymmdd
(year,month,day).
Authoring message - if you mean the name of the author of fdbg - it is completelly useless. I remember how much helped me turbo debugger in DOS and win32 so fdbg is hopped to help others in win64 and linux64 too. If you use fdbg and it helps you, that is big reward for me, and putting author's name there would only waste space and produce bigger executable (btw. there has been an easter egg in fdbg for a long time - several versions backward - since the begin of year 2007), and perhaps nobody has discovered it yet - the compression ratio... I like small files as every asm coder).

I think (perhaps only my private personal opinion) that the most valuable part of fdbg is disasm engine. Everything other there is OS specific. If somebody needs to write noncommercial debugger for another OS, then he/she may freely use fdbg disasm engine and write only OS specific part of the new debugger.

P.S. a bit off topic, only small note after seeing you picture more detailed:
code 2nd
401000 sub rsp,10
401004 mov rcx,0
40100B call qword [00000000004030C4] -> it seems API

1.
the rip is not aligned 16 at the time of calling API (Vista is extremely sensitive to it...)
401000 sub rsp,18 ; should be better (other choice: push rax, sub rsp,10)

2. mov rcx,0
you can use amd64 zero 64-bit extending of 32-bit operation and thus save 1 byte of REX prefix
401004 mov ecx,0 does the same
401004 xor ecx,ecx is the smallest solution - only 2 bytes instead of 6 bytes of mov rcx,0

You will find a lot of possibilities how to shrink any code if you look into it with debugger.

code 1st
40169B mov esi,[00000000004034F8] ; []=004035F0 ; good, it seems low dword of 64-bit memory pointer
...
sub esi,... ; may destroy (zeroing) upper dword of rsi
...
repz movsq
very dangerous combination before repz movsd - but you are sure that esi points into low dword of 64-bit memory pointer. If any data is above 0000000100000000 then you will cause exception.
mov rsi,...
sub rsi,...
repz movsq
sounds safer (but a bit bigger because of REX prefix - rsi instead of esi)

ufff, a bit looooong reply, OK, I'm ending... just joking
Post 11 May 2007, 12:22
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
1. Yeah, but I'm on 2003 Server and it doesn't give any errors. Btw, the code behind it is:
start:
invoke GetModuleHandle,0
2. But making it optimal would handicap the readability:
start:
xor ecx,ecx
invoke GetModuleHandle
hmm...

sub esi means that I only use DWORDs in the memory and if it wraps over, its needed Wink

Btw, that was some random test-code that I will scrap anyways Razz I'll post the resulting final code in the Project & Ideas section. There are the very clever algoritms there (some school projects).
Post 11 May 2007, 22:34
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4, 5 ... 9, 10, 11  Next

< Last Thread | Next Thread >
Forum Rules:
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 vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.