The gPXE's code can be executed on both real-mode and protected-mode because of the GDT's base address was filled with the starting point of the code. Which makes all the function, global variable's pointer valid between the transition.

The original design already put the 16bit code and data to the begining of the gPXE image. That reduced the posibility which might occur when running 16 bit code hit the 1MB limit.

The limit of GDT entry was set to 4G, so there is no need to concern if we are going to across the segment limit in 32 bits code.

Since the heap is not used by real-mode code, and is used at late stages of gPXE. I think it might be possible to put the heap out side of the .bss section, and put it at the very end of the image. After we put the heap at the very end of the image, we can make sure that no data accessed by 16 bits code would put higher than 1MB limit.

Currently I left 128KB for stack to grow, and put the heap right behind it. The C code which runs in protected-mode would work fine, since it's already using 32 bit addressing, and the segment limit is way larger than image size.

The most important thing that makes it possiable is the modification for relocate. 16 bits code do not access any memory that is not in .*16 sections in general except when copying(relocation) the gPXE image. After we ignore the copy of heap data, we can have virtually unlimited heap which can be decide on compile time.

Heap modification branch