Message board for the users of flat assembler.
> Projects and Ideas > FDBG - win64 Linux64 UEFI x64 AMD64 debugger
Goto page Previous 1, 2, 3, 4, 5 ... 10, 11, 12 Next
Garthower 24 Feb 2007, 09:44
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/
|24 Feb 2007, 09:44||
Madis731 27 Feb 2007, 13:19
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
|27 Feb 2007, 13:19||
Garthower 02 Mar 2007, 17:19
2Feryno: Do you can to add display of abnormal float numbers (negative infinity etc.) in a window of FPU/MMX data more corect?
Remove url to screenshot[/edit]
Last edited by Garthower on 20 Mar 2007, 16:43; edited 1 time in total
|02 Mar 2007, 17:19||
MazeGen 19 Mar 2007, 11:32
Would it be possible to add the address of the access violation to the fdbg's message?
Exception. ProcessId=0000034Ch ThreadId=000000D0h Address=0000000000401005h ExceptionCode=C0000005h=EXCEPTION_ACCESS_VIOLATION first_chance
...ExceptionCode=C0000005h=EXCEPTION_ACCESS_VIOLATION At Address=8000000000000000h
|19 Mar 2007, 11:32||
Feryno 19 Mar 2007, 14:51
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
|19 Mar 2007, 14:51||
Garthower 20 Mar 2007, 16:55
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.
|20 Mar 2007, 16:55||
Feryno 26 Mar 2007, 13:09
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...
|26 Mar 2007, 13:09||
Garthower 01 Apr 2007, 11:04
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...
|01 Apr 2007, 11:04||
Feryno 02 Apr 2007, 12:46
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
|02 Apr 2007, 12:46||
Garthower 11 Apr 2007, 01:36
I have a problem with FDBG. FDBG crashes at debugging this source code on command "xor rax,rax" (!!!)
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'
Maybe, it's connected by that I have install today SP2?
|11 Apr 2007, 01:36||
Tommy 11 Apr 2007, 06:33
mov qword [rax],0 -> mov qword ,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?
|11 Apr 2007, 06:33||
Garthower 11 Apr 2007, 11:56
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.
|11 Apr 2007, 11:56||
Feryno 13 Apr 2007, 08:06
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.
|13 Apr 2007, 08:06||
Garthower 13 Apr 2007, 08:56
Now it's stable. Thanks Feryno for operative reaction to a problems!
|13 Apr 2007, 08:56||
Quantum 13 Apr 2007, 15:44
VMWare 5.xx or higher can emulate x64-86 on 32-bit platform.
VMware Workstation 5.5.x:
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.
|13 Apr 2007, 15:44||
mattst88 17 Apr 2007, 19:34
Are you no longer making a Linux64 version?
|17 Apr 2007, 19:34||
Feryno 18 Apr 2007, 05:32
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.
|18 Apr 2007, 05:32||
Madis731 11 May 2007, 07:14
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
Btw, one small request:
-that under the Help menu > there could be About dialog with "Authoring message" and FDBG version.
|11 May 2007, 07:14||
Feryno 11 May 2007, 12:22
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
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:
401000 sub rsp,10
401004 mov rcx,0
40100B call qword [00000000004030C4] -> it seems API
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.
40169B mov esi,[00000000004034F8] ; =004035F0 ; good, it seems low dword of 64-bit memory pointer
sub esi,... ; may destroy (zeroing) upper dword of rsi
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.
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
|11 May 2007, 12:22||
Madis731 11 May 2007, 22:34
1. Yeah, but I'm on 2003 Server and it doesn't give any errors. Btw, the code behind it is:
2. But making it optimal would handicap the readability:
sub esi means that I only use DWORDs in the memory and if it wraps over, its needed
Btw, that was some random test-code that I will scrap anyways I'll post the resulting final code in the Project & Ideas section. There are the very clever algoritms there (some school projects).
|11 May 2007, 22:34||
|Goto page Previous 1, 2, 3, 4, 5 ... 10, 11, 12 Next
< Last Thread | Next Thread >
Copyright © 1999-2023, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.