home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   alt.os.development      Operating system development chatter      4,255 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 4,006 of 4,255   
   James Harris to wolfgang kern   
   Re: Q1-4: in UEFI boot basics   
   29 Nov 23 08:49:47   
   
   From: james.harris.1@gmail.com   
      
   On 28/11/2023 11:26, wolfgang kern wrote:   
   > On 28/11/2023 10:00, James Harris wrote:   
   >> On 27/11/2023 22:43, wolfgang kern wrote:   
   >>> On 27/11/2023 16:31, James Harris wrote:   
      
   ...   
      
   >>>> I agree. The reloc library code is not wanted.   
   >>>   
   >>>> That said, AISI I don't need it at present because my own code is   
   >>>> position-independent but if I ever need to have non-PIC code then   
   >>>> some form of PE-reloc code would be necessary.   
   >>>   
   >>> My code was/is always position independent w/o self-relocation needs   
   >>> because I know what goes where by using my brain instead of guessing   
   >>> what assembler/compiler might do.   
   >>> So I use immediate constants rather than dynamic RIP addressing.   
   >>   
   >> You'll still need to refer to your own data (such as a Hello message)   
   >> and will need the address of its first character. 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   
      
   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.   
      
   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]   
      
   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. UEFI is a lot more fussy than BIOS as to what it   
   will hand control to.   
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca