Hi,

So answering my own question, MS tooling does not include base relocs for
EXEs by default (although apparently a few others do, like Delphi, and base
relocs are embedded if building with ASLR)

I changed the implementation to also embed base relocs if subsystem is EFI
applications, EFI boot drivers and EFI runtime drivers, and the linker
option has been changed to -Wl,-no-strip-base-relocs, as suggested.

I also re-worked the cleanup patch to address Grischka's comment. We can
get rid of the clutter while still avoiding hard to understand (or
maintain) constants.

PE: clean up characteristcs/subsystem code
https://github.com/andreiw/tinycc/commit/b190796f26fe479db736b3387463bdfe262e99c5
PE: fix UEFI image generation
https://github.com/andreiw/tinycc/commit/c0827b0eb90deba4d7d3211c0aa4c6aa4cee3fd0
PE: experimental ARM64 support
https://github.com/andreiw/tinycc/commit/bfd77f13a45c62049fd5cf2f49534a5c75fcf7de

I tested this with OVMF on QEMU, VMware Fusion, ArmVirtPkg (AArch64 UEFI
for QEMU) and a few real ARM server platforms (especially ones that had no
RAM at the preferred loading address, forcing base relocs to be applied).


[image: Inline image 1]

[image: Inline image 2]
A

On Wed, Aug 23, 2017 at 8:57 AM, grischka <[email protected]> wrote:

> Andrei E. Warkentin wrote:
>
>> Dear tinycc-devel,
>>
>> A few more fixes for your review.
>>
>> - support for generating ARM64 PE32+ images
>> - support for generating X64, ARM64, IA32 (untested) and ARM (untested)
>> UEFI images.
>>
>
> I don't think we want relocation entries by default in x86/x86-64
> executables.  Maybe you can support -Wl,-no-strip-base-relocs
>
> Also pe32.h and the longish portions with IMAGE_SUBSYSTEM_*/IMAGE_FILE_*
> produce lots of visual clutter.  Maybe for something that changes once
> in 10 years, we can use just hex numbers as before.
>
> Other than that the patch seems to make sense.  On which system did
> you test this?
>
> -- gr
>
> https://github.com/andreiw/tinycc/commit/5267c3c291841cb3c3a
>> d1ec88b4ab91a16afc44b
>> (PE: clean up characteristcs/subsystem code)
>> https://github.com/andreiw/tinycc/commit/2df4e01b400211cce90
>> b3d427bf06dbad35bb453
>> (PE: fix UEFI image generation)
>> https://github.com/andreiw/tinycc/commit/5cf413024d4a4a163cb
>> f3a4f4329d75f3dd640f9
>> (PE: experimental ARM64 support)
>>
>>
>> The UEFI stuff was tested by building the following simple app (you need
>> Tiano edk2 for the headers).
>>
>> $ ./x86_64-win32-tcc -I ../edk2/MdePkg/Include/ -I
>> ../edk2/MdePkg/Include/X64/  ../efitest.c  -Wl,-subsystem=efiapp -nostdlib
>> -o ../efitest.x64.efi  -v
>>
>> $ ./arm64-win32-tcc -I ../edk2/MdePkg/Include/ -I
>> ../edk2/MdePkg/Include/AArch64/  ../efitest.c  -Wl,-subsystem=efiapp
>> -nostdlib -o ../efitest.aa64.efi
>>
>> -->
>> #include <Uefi.h>
>>
>> CHAR16 *gHello = L"Hello from a TinyCC compiled UEFI binary!\r\n";
>>
>> EFI_STATUS EFIAPI
>> _start(EFI_HANDLE Handle,
>>        EFI_SYSTEM_TABLE *SystemTable)
>> {
>>   CHAR16 *StackString = L"String pointer on the stack\r\n";
>>   SystemTable->ConOut->OutputString(SystemTable->ConOut, StackString);
>>   SystemTable->ConOut->OutputString(SystemTable->ConOut, gHello);
>>   return EFI_SUCCESS;
>> }
>> -->
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Tinycc-devel mailing list
>> [email protected]
>> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>>
>
>
> _______________________________________________
> Tinycc-devel mailing list
> [email protected]
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
A
_______________________________________________
Tinycc-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Reply via email to