What's the outlook, folks? Do I need to make further changes are am I okay to push to mob?
A On Sun, Sep 10, 2017 at 1:36 AM, Andrei Warkentin < [email protected]> wrote: > Well, there could many reasons why someone might wish to build a EXE with > base relocs, even in a non-UEFI scenario. This is equivalent to CL's > /FIXED:NO. One use case would be enabling base randomization (something > like /DYNAMICBASE, not addressed by my work). Another one would be wishing > to LoadLibraryEx an EXE image into your existing address space, which will > most certainly not work if there are no base relocs in the image being > loaded. > > I don't really have a strong opinion. If you want it gone, I'll clean it > up. Otherwise fine? > > A > > > 9 сент. 2017 г., в 17:05, grischka <[email protected]> написал(а): > > > > Andrei Warkentin wrote: > >> Any thoughts, folks? I reworked the changes, as requested. > > > > Well, what's now the point to have the switch > > "-Wl,-no-strip-base-relocs" > > exactly? What are people supposed to do with it? > > > > -- gr > > > >> 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 > > > > > > _______________________________________________ > > 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
