Any thoughts, folks? I reworked the changes, as requested. A
> 26 авг. 2017 г., в 22:44, Andrei E. Warkentin <[email protected]> > написал(а): > > 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.png> > > <image.png> > 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/5267c3c291841cb3c3ad1ec88b4ab91a16afc44b >>> (PE: clean up characteristcs/subsystem code) >>> https://github.com/andreiw/tinycc/commit/2df4e01b400211cce90b3d427bf06dbad35bb453 >>> (PE: fix UEFI image generation) >>> https://github.com/andreiw/tinycc/commit/5cf413024d4a4a163cbf3a4f4329d75f3dd640f9 >>> (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
