From: james.harris.1@gmail.com   
      
   On 08/02/2022 13:49, wolfgang kern wrote:   
   > On 07/02/2022 14:06, James Harris wrote:   
   >> On 09/01/2022 10:44, wolfgang kern wrote:   
      
   ...   
      
   >> I don't get that. If you had instructions like   
   >>   
   >>    mov ebx, [0x7c00]  ;Get pointer from start of image   
   >>   
   >> then you would need to know where the image started (0x7c00) ... and   
   >> if you knew where the image started you wouldn't need relocation.   
   >>   
   >>>   
   >>> more previous versions used a relative CALL-Null/POP sequence to   
   >>> figure where it was loaded, but I soon found the better solution as   
   >>> said above.   
   >>   
   >> I could see value in loading a pointer from a fixed location in   
   >> memory, e.g.   
   >>   
   >>    mov ebx, [0x1004]  ;Get pointer to globals   
   >>   
   >> but not from the start of a movable image.   
   >   
   > OK, we know that the (old yet) BIOS starts our code at 7C000.   
      
   I take it you mean address 7c00 (31k).   
      
   > So all we have to do is to make sure that all our references   
   > either align to (flat) 0:7c00 or (seg:offset) 7c00:0000.   
      
   Yes (though seg 07c0).   
      
   > My 16 bit MBR starts with a hard coded far jump to 7c00:0040   
   > to leave some room for variables and align to cache bound.   
   >   
   > And all the stuff I load after the initial boot, self-relocating   
   > is just done by remember the location where I put it and store   
   > this (32 bit flat xxxx) value into the image.   
   > e.g.: a first local data pointer init   mov esi,xxxx   
   > aka: BE xx xx xx xx   
   > this is also stored into my MEM-LISTING to be used for external   
   > and inter instance referencing.   
   > works the same if code modules were moved, what I never did.   
   >   
   > Previous versions used: call 0000 | pop esi   
   > E8 00000000   
   > 5E          must be aware of the five bytes off here.   
      
   That's basically what I ended up doing. In fact, my code includes   
   sequences such as   
      
      call _ip_get   
      add eax, label - $   
      
   where $ is the address of the add instruction, label is the intended   
   label and ip_get is   
      
      mov eax, [esp] ;Fetch return EIP   
      ret   
      
   I did it that way to match calls with returns so as not to upset the RSB   
   although I gather that E8 0000_0000 is recognised as an idiom in many   
   CPUs and doesn't cause any problems with branch prediction.   
      
   That approach wouldn't work where there are instances at different   
   addresses relative to EIP but it works fine for the single-instance case   
   of booting.   
      
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)