This is a living document. Everything in this document is made in good faith of being accurate, but like I just said; we don't yet know everything about what's going on.
Update: I've disabled comments as of 2025-01-26 to avoid everyone having notifications for something a year on if someone wants to suggest a correction. Folks are free to email to suggest corrections still, of course.
(or nearly so...)
GDB is undeniably an extremely versatile debugger, with the ability to add breakpoints, watchpoints, dump memory, registers, and the source code (along with its corresponding assembly). These features make it the perfect Swiss Army knife for most programmers. In addition to that, the possibility of implementing a 'GDB Stub' and automatically supporting GDB in your application makes it an almost universal debugger for a variety of tasks.
Qemu, like other virtual machines (such as 86Box), also implements debugging via GDB Stub, which enormously facilitates the development of bootloaders, operating systems, and more. The support for 32-bit and 64-bit code is quite good, and I have never seen any complaints about it. However, for 16-bit/real mode...
If you have ever tried to debug 16-bit code on Qemu, you know how painful it can be:
When I was working on a generic port of Google's hashmap to C, I wrote a function that (ignoring irrelevant parts) looked like this:
typedef struct {
uint8_t *bytes;
size_t len;
} bytebuf;
got ---> global offset tablevirtual address space (VAS) or address space ---> is the set of ranges of virtual addresses that an operating system makes available to a process.
Things required:
Assumptions: Host machine is linux.
/boot/config-$(uname -r) to .config in the extract linux src code folder..config has the following options: CONFIG_FRAME_POINTER=y , CONFIG_KGDB=y , CONFIG_KGDB_SERIAL_CONSOLE=y , CONFIG_KGDB_KDB=y , CONFIG_KDB_KEYBOARD=y. Change if necessary. Alternatively use make xconfig to configure in UI.sudo apt-get install build-essential libncurses-dev bison flex libssl-dev libelf-dev)
This explains how to build mesa from source, and how to use the custom built mesa to run some apps and games, without needing to replace the mesa libraries that your operating system runs on.
Let's assume that you are using an x86_64 system.
In computer science, the event loop, message dispatcher, message loop, message pump, or run loop is a programming construct that waits for and dispatches events or messages in a program.
It works by making a request to some internal or external "event provider" (that generally blocks the request until an event has arrived), and then it calls the relevant event handler ("dispatches the event").
The event-loop may be used in conjunction with a reactor, if the event provider follows the file interface, which can be selected or 'polled' (the Unix system call, not actual polling).
The event loop almost always operates asynchronously with the message originator.