[SOLVED]Does the data record in elf and in pecoff behaves differently?

[TYDQ]

I have tested many times about data record behaviour in elf and in pecoff.I suspected that When reading data record or writing data record,linux's order and windows's order are completely different.However,this conclusion maybe wrong and I am mistaken.
While reading the assembly code fpc have generated,I discovered that the same data record is placing in the .rodata(elf),.data(windows),Does the different position made the data record reading and writing different from platforms?

[PascalDragon]

I have tested many times about data record behaviour in elf and in pecoff.

What kind of data record do you mean?

[TYDQ]

I have tested many times about data record behaviour in elf and in pecoff.

What kind of data record do you mean?

It is just a record like that:

Code: Pascal  [Select][+][-]

1. efi_system_table=record
2.                       hdr:efi_table_header;
3.                       FirmWareVendor:^WideChar;
4.                       FirmWareRevision:dword;
5.                       ConsoleInHandle:efi_handle;
6.                       ConIn:^efi_simple_text_input_protocol;
7.                       ConsoleOutHandle:efi_handle;
8.                       ConOut:^efi_simple_text_output_protocol;
9.                       StandardErrorHandle:efi_handle;
10.                       StdErr:^efi_simple_text_output_protocol;
11.                       RuntimeServices:^efi_runtime_services;
12.                       bootservices:^efi_boot_services;
13.                       numberofTableEntries:NatUint;
14.                       configuration_table:^efi_configuration_table;
15.                       end;

When use this record such as efi_allocmem,the assembly code generated by fpc in elf files:

Code: ASM  [Select][+][-]

1. EFI_ALLOCMEM:
2. .Lc11:
3. # [2879] begin
4.         leaq    -40(%rsp),%rsp
5. .Lc12:
6. # Var res located at rsp+32, size=OS_64
7.         movq    %rdi,%rdx
8. # Var size located in register rdx
9. # [2880] GlobalSystemTable^.BootServices^.AllocatePool(EfiLoaderData,Size,res);
10.         leaq    32(%rsp),%r8
11. # Var size located in register rdx
12.         movl    $2,%ecx
13.         movq    U_$UEFI_$$_GLOBALSYSTEMTABLE@GOTPCREL(%rip),%rax
14.         movq    (%rax),%rax
15.         movq    96(%rax),%rax
16.         call    *64(%rax)
17. # Var $result located in register rax
18. # [2881] efi_allocmem:=res;
19.         movq    32(%rsp),%rax
20. # [2882] end;
21.         leaq    40(%rsp),%rsp
22. .Lc13:
23.         ret

And that is assembly code in pecoff:

Code: ASM  [Select][+][-]

1. EFI_ALLOCMEM:
2. .Lc11:
3. .seh_proc UEFI_$$_EFI_ALLOCMEM$QWORD$$POINTER
4. # [2879] begin
5.         leaq    -40(%rsp),%rsp
6. .Lc12:
7. .seh_stackalloc 40
8. .seh_endprologue
9. # Var res located at rsp+32, size=OS_64
10.         movq    %rcx,%rdx
11. # Var size located in register rdx
12. # [2880] GlobalSystemTable^.BootServices^.AllocatePool(EfiLoaderData,Size,res);
13.         leaq    32(%rsp),%r8
14. # Var size located in register rdx
15.         movl    $2,%ecx
16.         movq    U_$UEFI_$$_GLOBALSYSTEMTABLE(%rip),%rax
17.         movq    96(%rax),%rax
18.         call    *64(%rax)
19. # Var $result located in register rax
20. # [2881] efi_allocmem:=res;
21.         movq    32(%rsp),%rax
22. # [2882] end;
23.         nop
24.         leaq    40(%rsp),%rsp
25. .Lc13:
26.         ret
27. .seh_endproc
28. .Lc10:

Does the movq   U_$UEFI_$$_GLOBALSYSTEMTABLE(%rip),%rax and movq   U_$UEFI_$$_GLOBALSYSTEMTABLE@GOTPCREL(%rip),%rax behaves differently?

[Laksen]

GOTPCREL refers to the global offset table. This is just a detail of how the target is configured. Since you are relying on the Linux or Windows target as a hack you should set it up during RTL initialization as if you were on windows or Linux

The proper fix is to create a new fpc target for UEFI with a proper RTL

[TYDQ]

GOTPCREL refers to the global offset table. This is just a detail of how the target is configured. Since you are relying on the Linux or Windows target as a hack you should set it up during RTL initialization as if you were on windows or Linux

The proper fix is to create a new fpc target for UEFI with a proper RTL

I'm developing a software called elf2efi(elf to efi translator),I don't need an new Runtime library.
My code compile with using -n and -Xd these times.