From: james.harris.1@gmail.com   
      
   On 27/11/2023 22:43, wolfgang kern wrote:   
   > On 27/11/2023 16:31, James Harris wrote:   
      
   ...   
      
   >>> UEFI comes with C-libraries ?   
   >>> I'd delete them immediate :)   
   >   
   >> 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.   
      
   ...   
      
   >>>>>> struc efi_systab ;UEFI system table   
   >>>>>>    .hdr:      resb efi_hdr_size   
   >>>>>>    .fvend:    resq 1 ;FirmwareVendor   
   >>>>>>    .frev:     resd 1 ;FirmwareRevision   
   >>>>>>               resd 1 ;padding   
   >>>>>>    .coninh:   resq 1 ;ConsoleInHandle   
   >>>>>>    .conin:    resq 1 ;ConIn   
   >>>>>>    .conouth:  resq 1 ;ConsoleOutHandle   
   >>>>>>    .conout:   resq 1 ;ConOut   
   >>>>>> endstruc   
   >>>   
   >>>>>> The header is   
   >>>>>   
   >>>>>> struc efi_hdr ;Generic header   
   >>>>>>    .Signature:    resq 1   
   >>>>>>    .Revision:     resd 1   
   >>>>>>    .HeaderSize:   resd 1   
   >>>>>>    .CRC32:        resd 1   
   >>>>>>                   resd 1  ;reserved   
   >>>>>> endstruc   
   >>>   
   >>> I try to convert the above: (pointed to by RDX)   
   >>> efi_systab:   
   >>> 000 dq ptr to efi_header   
   >>> 008 dq STR16ptr to FirmwareVendor  ;UTF16   
   >>> 010 d  FirmwareRevision   
   >>> 014 d  0000_0000   
   >>> 018 dq handle for ConsoleIN   
   >>> 020 dq ptr tp ConsoleIN   
   >>> 028 dq handle for ConsoleOut   
   >>> 030 dq ptr to ConsoleOUT   
   >>> ----------------------------   
   >>> efi_header:   
   >>> 000 dq Signature   
   >>> 008 dq Revision   
   >>> 010 q  Headersize (in bytes) wouldn't it just say 0000001c ?   
   >>> 014 q  CRC32                 ;of what ???   
   >>> 018 q reserved ....   
   > =======================   
   >   
   >> If the 3-digit numbers are offsets then not quite. If the header is 24   
   >> bytes then when struc efi_systab specifies   
   >>   
   >>    .hdr:      resb efi_hdr_size   
   >>   
   >> it is reserving 24 bytes at the start of the system table.   
   >   
   > I don't get that at all.   
   >   would you mind to correct my above translation in my format ?   
      
   I'm not sure I understand enough of your format to do that but if the   
   first three digits are the offsets in decimal then I think the System   
   Table in 64-bit mode would begin something like   
      
   000 24-byte  Hdr   
   024  8-byte  FirmwareVendor   
   032  4-byte  FirmwareRevision   
   036  4-byte   (unnamed padding)   
   040  8-byte  ConsoleInHandle   
   048  8-byte  ConIn   
   056  8-byte  ConsoleOutHandle   
   064  8-byte  ConOut   
   072  8-byte  StandardErrorHandle   
   etc   
      
   That's based on the header at 4.2 and the System Table at 4.3 and   
   noticing that I added padding to align the next field and finding that   
   according to 2.3.1 the EFI_HEADER type is void* which is a pointer which   
   would be in C terms a pointer to void (which one could think of as a   
   pointer to an undeclared type but all we need to know is that it's a   
   pointer, i.e. 8-bytes in 64-bit mode). Phew!   
      
   *IOW* there's a lot of assumptions and a bunch of manual transcription   
   in the offsets I've written so they may not all be correct but hopefully   
   the idea and the comments provide enough info for you to get a little   
   further forward. Feel free to tell me of any errors and do check out the   
   types in 2.3.1 remembering that in C declarations an asterisk means a   
   pointer so T* means a pointer to T.   
      
   You may prefer shorter names, as I did. I took the above field names   
   from the spec's description of the System Table (at 4.3).   
      
      
   --   
   James Harris   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)