@FlierMate11 Try http://fdbg.x86asm.net/

Cool, FDBG is hosted there, the same website I use for disassembler reference (http://ref.x86asm.net/) days ago.

Thank you.

BTW, I have to say this is great work (elf/linux on AMD64).

I wish I could set a breakpoint using a defined symbol from the dynamic segment/.dynamic section.

FlierMate11 - I don't plane to put it on GitHub.
sylware - I implemented only very simple symbols, there are samples_debug_symbols
The beauty of FASM is that it was possible to port debugger to win x64, linux x64, uefi x64
MazeGen was very helpful in hosting fdbg on his site.

Yeah, I saw you were using the ELF classic symbol section. No worrie here since I think we can instruct the linker to create such section with the symbols you would like to debug.

If you want to debug a binary though, the "exported symbols" are in the dynamic symbol table, which is different from the classic symbol table.

No worries, it is just to make you aware of it.

Great work though !

Yep, good stuff and not just for debugging. I found the source code really helpful when I was trying to implement exception handling under UEFI. For some reason that I don't understand on my x64 system UEFI uses EBC ISA for debugging and not x64. Instead following Feryno's IDT route works a treat. Thanks for the insight @Feryno.

Yes that was the biggest challenge in UEFI, how to create something which is called "debug loop" in ms win (WaitForDebugEvent / ContinueDebugEvent) and ptrace system call in Linux. Finally I got the "bare hands" idea:
replace all UEFI exception handlers with own (using IDT)
run executable
on any exception restore original UEFI exception handlers

Carefull of the memory page attributes, because it seems UEFI is planning to enable the usage of write and exe attributes on some pages.

Then before replacing anything in UEFI code, you should be sure to have write access to that part of UEFI code/data and your debugger code pages have not the nexe bit on.

I added a "p" command into fdbg for uefi. It writes a byte into i/o port 80h. These data are transmitted via ASUS COM_DEBUG port and very likely ASROCK UART1 port. You need a cheap USB to TTL device and a second computer to grab the data using putty utility. Using this command you can test easily whether your setup works. Useful when you cannot touch serial port either graphics output or if your project causes serious crash when nor serial port either graphics is responding.
For more about the hardware setup:
https://forum.osdev.org/viewtopic.php?f=1&t=56069
https://youtu.be/Gnm_tuARqVI