Piotr Jaroszyński: Usermode debugging under Linux

Allowing gPXE to run as a usermode application requires implementing APIs that are normally provided by BIOS, EFI or hardware.

To implement all the APIs an interface to kernel is needed in the first place. Following are two possible approaches:

Hack stdlibs to make them linkable with gPXE/

• + use the standard well tested library (still plugging it in as low as possible)
• + support many arch/OS combos out of the box
• - potential unforeseen interactions
• - less flexibility

Starting with syscall() in assembler and implementing necessary functionality based on it as needed.

• + full control of initialization
• + avoid additional dependency
• - reinventing the wheel
• - work needed to add support for additional architectures (moot if no demand + shouldn't be too much work anyway)
• - work needed to add support for additional OSes (moot if no demand + there will be other bigger linux-specific parts anyway)

I am going to implement them both as it's a great learning experience. Own implementation of stdlibs' functionality is going to be used in the end probably as it seems to better fit gPXE nature if nothing else.

Prefix complexity varies depending upon whether stdlibs will be used and whether testing decompress() (at least the 32bit version on i386) is desirable. Without stdlibs, initialization will need to be reimplemented. Testing decompress will need some extra magic. Complexity of the linker script depends upon decompress alone, if not desirable adding only the table magic to the default script should work.

Networking may be provided at different layers. Layer 1 is a must-have. Layer 0 would be extra nice for drivers developers, but requires a lot of work. Layer 2+ would be nice for isolating specific layers for testing/benchmarking and shouldn't be too hard. Considering everything except Layer 1 as extra.

Implement a virtual driver with packet sockets.

Should be doable with UIO. DMA would need some extra work, I have seen patches adding it to UIO, but they weren't ready yet.

Replace gPXE's implementations with appropriate kind of sockets.

Trivially mapped to appropriate syscalls.

Access should be trivial as processes have flat address space. Allocating memory will most likely require reimplmenting something like posix_memalign().

Flat addressing saves us the problems.

Seems to be only used by the drivers and other stuff that we won't be running in the userspace anyway. At least until tackling Layer 0 implementation, but that needs a lot of thinking through.

Is anything using this at all? Certainly doable as there is an opensource libsmbios.

Nothing is going to be really booted but appropriate debug info about the loaded images can be given.

Some refactoring will be needed to be able to test all things as currently many features are included only in i386 - e.g. most of IMAGES_*.