I found the problem:
the variable "debug_ctl_available" was not declared in my source.
I wonder why Fasm did not report that.
Anyway, i managed to successfully compile the rest of fdbg together with my sources.
Now, I need to get the break mechanism to work.

Thanks to "revolution" for hinting me.
Thanks to "Feryno" for his indispensible Fdbg.efi.

Hi, two (not urgent) questions:

The "handle_exception" functions seems a simple wrapper around the "wait_command" function, giving it 8 reserved bytes on the stack.
What is the function of this wrapper, and is it needed?
Note that the rbp register must be preserved !

I do not use protected mode in my EFI projects.
So, is it save to remove the many alignment directives in code and data?

Thanks again.

Hi Seppe,
I planed to execute more things in exception handler. Currently the only thing executed is wait_command. You may destroy RBP register in wait_command proc as all registers are saved before calling exception_handler and also restored after returning from exception_handler. The wait_command proc is able to modify registers pushed before calling handle_exception (e.g. command like r rax=0) so after returning from exception_handler these modified registers are restored.
Yes it is safe to remove align directives.
I didn't yet see any EFI which does not run in protected mode. Every EFI starts in real mode from address F000:FFF0 and switches to protected mode in few instructions. CSM (compatibility support module) is able to load MBR to physical memory 7C00h, switch from protected mode to real mode and execute JMP 0000:7C00 (emulate BIOS boot mode).

Hi Feryno,

I just got the essential functions (disa, int3, step, trace) to work.
Because my debugger is resident, I can now debug EFI drivers or other resident boot software.

Concerning our previous conversation:

. I removed the "handle_exception" wrapper from my sources. (ok)
. I will remove the redundant alignment directives in a later stage. (ok)
. I insist that rbp must be preserved because its value is used in the bracketing enter/leave. I report this to prevent other developers from repeating my mistake.
. Yes, I use your sources to implement native debugging for resident efiboot software, long mode 64-bit and compatibility mode, but no protected mode.

I would like to share my work and experience with other Fasm/UEFI developers.
But I wonder if this flatassember forum is a good place to do so.
This flatassembler forum does not allow me to post efi files.
Also, many topics will concern UEFI matters which have nothing to do with Fasm.
I don't like "StackOverflow" because many gurus downvote questions they dont like or understand.
I prefer a forum that is dedicated to assembly programmers, because I fear that c-programmers (tiano) may spoil things.

Do you have a suggestion?

Hi Seppe, post it here, make a zip archive. Your work is very useful.

Then I think I should create a new thread "flat assembler > Projects and Ideas > UEFI matters".
Are you sure that the thread will not be rejected by the forum board, knowing that many topics will have little or nothing to do with Flat assembler?

I attach a small zip file just to make sure that it is possible to communicate efi executables.

If you post fasm source code then I can't see a problem.

If it really does have nothing to do with fasm then there is the "Heap" section.

Hi Feryno,

I implement your branchlist command, because it is very useful to debug a driver that causes a system error.
The list shows 8 branches on my PB easynote laptop.
The list shows 16 branches on my HP650 laptop.
The additional line is always "lef=00000000 let=00000000".
A problem is that most (if not all) lbf addresses point to the same code, where there is a iretq operation.
I think it must be possible to elaborate the w command to have a more useful branch history, or . . .

I think of an option to the "g" command to start branch recording in a large circling buffer, using the BTF feature, and a command to print this history in reverse order.

I find the descriptions in the AMD and Intel manuals very poor.
Maybe you have ideas or hints to avoid me wasting time on this.
Or maybe a good publication on the net . . . ?

Hi Seppe, Intel manual is very detailed. There are 3 various choices for MSRs used for last branch recording feature. LBF/LBT vary from 4 to 16 pairs of registers depending CPU you have. There is even fourth newest feature not implemented in fdbg and that's BTS where you can record into memory buffer more than 16 pairs as via MSR method.

http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html

chapter 17.4 in this manual:
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3b-part-2-manual.pdf

chapter 35 in this manual:
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3c-part-3-manual.pdf

I don't plane to develop fdbg further as I spent and will spend time for programming on something else (for very long time and a some people depend on my work and for these people programming is primary job, for me only hobby and side job in free time so my time for programming is quite limited).

I have just installed the fdbg debugger to enable me to debug some code written using [b]fasm[b].

First of all, my compliments to the author of fdbg ...

it is a very well thought out, clean and self-contained program that works very well, and it is so nice that it recognises fasm symbols.

It is a pleasure to use a tool like this after all of the incredibly complicated and difficult to use tools I have encountered in general.

On to my question.
In my fasm assembly code I am referencing MMX registers,
but the fdbg 'r' command only lists the standard registers:
[rax, rbx, rcx, rdx, rsp, rbp, rsi, rdi, r8, r9, r10, r11, r12, r13, r14, r15, rip, rflags]

Does anyone know if there any plans to add the ability to view the status of the MMX and/or SSE registers to fdbg?

My apologies !
I did not read the help file properly.

in section: 05 displaying and changing registers
it clearly states that the status of MMX and other registers can be accessed.

Feryno,
Great job on FDBG. Out of curiousity I am having a question about the listview you're using to display disassembled instructions.
From what I can see in the source (I am new to FASM) you're using a regular listview and not a virtual listview?
How are you keeping the resources so low when adding items to a listview.
My experiences are when adding a lot of items to a regular listview it is taking a lot of resources from the system.
Could you englighten how you did it for FDBG?

Hi snoopy4567$, you are right. But the count of items in listviews is at range of hundreds, so performance is acceptable. Filling 10000 items would last few seconds. The performance decreasing is very nice visible when using older and never OS, e.g. when comparing oldest possible XP_x64/win_srv_2003_x64 with never like win8_x64 and filling 10000 items...
I'm not satisfied with GUI I used for ms win version, but I won't plane to change it in feature. But the GUI is quite easy to use also for everybody even without reading help file. I released src so everyone may modify/improve what he needs/knows/lacks.
Best regards, Feryno

Heya Feryno,

What do you mean with: But the count of items in listviews is at range of hundreds, so performance is acceptable.
I see in the source that you are calling SendMessage with the LVM_GETCOUNTPERPAGE, are you filling in like 100 items at the same time and than stop that process and start adding when user scrolls the listview and add another 100 items till the file is disassembled?

Hi snoopy4567$, yes, only visible items are displayed, e.g. nothing for minimized window. For code and data windows there is some max. limit (e.g. not to display thousands of disasembled instructions / thousands of bytes in data). If the performance is bad (older CPU and newer OS) you can minimize a lot of unused windows and then have better performance.
I think OS also optimizes updating items, it is faster for invisible items (e.g. window at bottom) and slowlier for visible (window on top).

Thanks for the information Feryno, I am gonna experiment further with the listviews.

Can a UEFI boot aplication know if it is loaded and launched via FDBG?

On my system, the UEFI interrupt handlers take 8 bytes when FDBG is not loaded, and take 32 bytes when FDBG is loaded.
I use this tric in my source debugger to check if FDBG is loaded or not.
But Feryno may have a better method.

Hi Feryno

I finaly can continue my UEFI project that I left of in 2015.
I hope you can find some free time to enjoy your hobby.
_________________
Greetings from Seppe

Hi seppe,
i think UEFI app cannot know its parent because LoadImage either StartImage do not contain any info about parent. But you can check IDT as you did, fdbg replaces interrupts with its own so then every interrupt handler is 20h bytes small (just a stub) and aligned at 20h. Your method is the only one and very clever trick.
I'm glad that you can continue your UEFI project and restart it after 3 years.
Of course I'm still programming in fasm as a hobby, especially debugging skills helped me a lot in the past years.

Divide overflow

Just a proposal to Feryno . . .
In x64, a divide overflow generates a #DE (divide error) exception, rather than setting the CF flag.
So the FDBG #DE exception handler could display "divide_overflow_exception" when the divisor is none zero.
Or simply display "divide_exception".

To my surprise, FDBG is not on GitHub! The closest I can find is :


It is a loss for open-source community on GitHub.