From: nowhere@never.at   
      
   On 29/11/2023 09:49, James Harris wrote:   
   > On 28/11/2023 11:26, wolfgang kern wrote:   
   ...   
      
   >>> How would you get the right address if you don't work it out relative to   
   RIP? AIUI the UEFI firmware makes no guarantees as to where it loads you code.   
      
   >> while with 32bit it can use CS override.   
   >> with 64bit I need a one time "where I am" like:   
   >> CALL next   
   >> next:   
   >> POP R15   
      
   > A few points:   
   >   
   > 1. x86 32-bit UEFI boot may not be widely supported. You may be better   
   > to be able to boot a 64-bit UEFI OS loader and switch to 32-bit mode if   
   > you want to start a 32-bit OS.   
   >   
   > 2. If UEFI load addresses aren't guaranteed then consider these scenarios:   
   >   
   > a) Code at 1000, data at 1400   
   > b) Code at 2000, data at 2400   
      
   I cannot believe that it may randomly load to different locations.   
   there must be some rule ie: dependent on media sector size.   
      
   > What you need is data /relative to code/. Having a CS override wouldn't   
   > help if you don't know where your code and data will be relative to CS.   
      
   when I write the file I know the data offset from within the code.   
   yours is 0x0400 for the text test. Mine will be much larger (>64K).   
      
   > 3) If writing a 32-bit UEFI OS loader you could use call/pop to get data   
   > address relative to wherever the code happens to have been loaded.   
   >   
   > 4) In x64 you don't need call/pop but can use RIP-relative references as in   
   >   
   >    lea rdx, [rel msg_hello]   
   >   
   > for which the hex is   
   >   
   >    48 8d 15 e7 1f 00 00     lea    rdx,[rip+0x1fe7]   
      
   OK I see it, but it is limited to 64k distance (same as in 32bit).   
      
   my one time self relocation used on start of several temporary dynamic   
   loaded modules (all static stuff is at fixed offsets as part of OS).   
      
   E8 0000_0000  CALL next   
   5A            POP  ESI   
   ...           adjust with known offsets   
      
   How would a 64bit version with larger than 64k code size look like?   
      
      
   > 5) The choices are to write PIC code or use relocation but bear in mind   
   > that UEFI firmware has to see your final PE file as something it is   
   > willing to load and execute so it might expect some flags or indicators   
   > to tell it that the file is PIC or, failing that, that it comes with a   
   > relocation section.   
      
   you mean UEFI will disassemble my code before loading it ?   
   we need to learn what exactly is required to make UEFI load and execute.   
      
   > UEFI is a lot more fussy than BIOS as to what it will hand control to.   
      
   Oh yeah, that was the reason for I stopped all business with KESYS.   
      
   BTW, you have a working text test?   
   can you read out a few registers and print the values?   
   it would be interesting what we get on start, especially RSP.   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)