From: noemail@basdxcqvbe.com   
      
   On Sat, 8 Jan 2022 13:37:34 +0000   
   James Harris  wrote:   
      
   > The problem is that the main executable needs to have fixups applied    
   > before it can be run.   
      
   Why do you need fixups applied?   
      
   Is this due to the type of executable being used?   
      
   Is this due to you moving position-dependent code?   
      
   What is generating the instruction below?   
      
   (FYI, from one line of assembly, it's hard to figure out where or why   
   the problem you have exists, as it could be from multiple things.)   
      
   > I need to correct the 'location of label gdt' field in the [below]   
   > instruction.   
   >    
      
   What is generating that instruction?  Assembly?  C code?  In both   
   cases, I'd think you should be able to convert "gdt" to an indirect   
   address or variable.  Then, you can play around with what's stored in   
   the variable.   
      
   > For instance, if it includes an instruction such as   
   >    
   >    mov ebx, gdt   
   >    
   > then that becomes an absolute load:   
   >    
   >    b8    
   >    
   > where b8 is the opcode in hex.   
   >    
      
   By "absolute load", you mean you can't change the binary value of   
   "" stored within the binary object, yes?   
      
   (Sorry, I was confusing what you said, "absolute load", with "absolute   
   address" for quite a while ...)   
      
   If you're generating this instruction from assembly, you can change it,   
   so it generates an indirect address loading from memory.   
      
   If a compiler is generating this instruction, I'd wonder why it was   
   doing that, i.e., it should access a C variable stored in memory, i.e.,   
   an indirect access.  E.g., I'd expect something more like "mov ebx,   
   [gdt_pointer]" where gdt_pointer is the memory address where   
   the address of gdt is stored.  Of course, you can do that for assembly.   
      
   You might be able to fix up issues like a gdt pointing to an incorrect   
   location by adjusting either the 16-bit RM segment for CS/DS or the   
   32-bit/64-bit PM base address for CS/DS (stored in the descriptor for   
   the PM selector).   
      
   That solution will work well for position independent code.   
      
   For position dependent code, the code might attempt to access memory   
   regions outside the application space, e.g., memory-mapped or below 1MB   
   on x86.  If the position dependent code is loaded to some address other   
   than what it was compiled for, accessing these "outside" memory regions   
   won't work.  You'd need to code special functions to make these memory   
   regions available from your relocated/moved code.  This is usually done   
   by creating additional CS/DS selectors for the low memory or memory   
   mapped device.  Execution is transferred from one code segment to   
   another, the function does the work, then returns.   
      
   > What do you do in the 32-bit code where you use absolute references   
   > such as the   
   >   
   >   mov eax, gdt   
   >   
   > that I mentioned in my prior reply?   
      
   The vast majority of the 32-bit code in my OS is compiled C.  So, I'm   
   not generating any "mov eax, gdt" or similar instructions in inline   
   assembly in C.   
      
   My OS is entered directly from 32-bit PM via the bootloader (or from my   
   DOS startup TSR).  The GDT for my OS is actually set up twice.  My OS   
   inherits a minimally functional GDT from the bootloader (or from my DOS   
   startup TSR).  I don't access the inherited GDT from my OS, as it's   
   "discarded" immediately.  My OS immediately sets up it's own proper GDT   
   in C, using an array of descriptors (typedef'd structs) for the GDT,   
   and loads the gdt via inline assembly for lgdt instruction.  If I need   
   to access the OS' gdt, it's accessed directly from C variables and   
   functions.   
      
   I do wrap a large variety of x86 system instructions such as lgdt, lidt,   
   ... in inline assembly.  These x86 instruction functions are passed the   
   C variables directly.  The C compiler patches the C code and assembly   
   code together correctly.   
      
   > Because of what is, admittedly, a policy decision, i.e. that I don't    
   > want to require the code to be in a fixed location   
      
   From this, my guess is that it seems like your compiler is producing   
   position-dependent code, but you're wanting position-independent code?   
   ...  If so, that's a problem.   
      
   If you load a position-dependent PM executable or object compiled for   
   1MB to say 2MB, you can adjust the base address of the PM selectors for   
   CS/DS from 1MB to 2MB.  However, that won't fix any accesses to   
   memory-mapped devices or stuff below 1MB.  To do that, you have to set   
   up additional CS/DS selectors for those regions, and you'd have to code   
   and call functions that transfer to code in those regions, do the work,   
   then return to your image.   
      
   The DJGPP compiler is a prime example of this.  It uses GCC C compiler   
   but a custom DOS library.  To access things below 1MB, you call special   
   functions.  The DJGPP images can be loaded anywhere above 1MB because   
   they're position independent.  OpenWatcom on the other hand, is position   
   dependent.  It's images are only intended to be loaded to the compiled   
   for address.  If you move an OW image from it's compiled for address,   
   you can't access memory or devices outside the image space, without   
   coding your own functions to access these regions, like DJGPP ...   
      
   --    
   Once a President becomes a permanent failure, he then becomes a   
   fearmonger.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)