tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] ARM64 PE32+ and UEFI support


From: grischka
Subject: Re: [Tinycc-devel] ARM64 PE32+ and UEFI support
Date: Mon, 18 Sep 2017 20:48:50 +0200
User-agent: Thunderbird 2.0.0.23 (Windows/20090812)

Andrei E. Warkentin wrote:
What's the outlook, folks? Do I need to make further changes are am I okay
to push to mob?

I'd say in general it's good, maybe too good for tinycc purposes in
some aspects:

* in tinycc as it is not all options do make sense for all targets,
  you could save some #ifdefs by accepting this non-perfection.
  (Instead you could throw an error in the tccpe backend if -shared
  was given)

* we trust the user to use valid filenames, the truncation for len > 8
  looks like overdesign and like a strange quick hack at the same time.

* if you want pe32.h, then move the other winnnt definitions from tccpe.c
  into it, also.  Or use tccpe.h as its own include file instead. (see
  TARGET_DEFS_ONLY in xxx-gen.c).  In any case, include only 'ifndef _WIN32',
  otherwise it can produce conflicts with windows.h->winnt.h.

* the switch "-no-strip-base-relocs": confusing double negation - you
  could find a better/shorter name.  Also, there is infrastructure to
  support -no prefixes quasi automatically.  Or you could just omit the
  option, for now.

* the uefi-example, shouldn't it go to win32/examples?

* you might add a short note in tcc-win32.txt about the state of UEFI support.

* In general I'd prefer less lines over auto generated comment headers
  (I'm getting picky ...;)

Just suggestions.  Like everyone you are free and welcome to commit to mob
whatever according to your own considerations is adequate to both your goals
and the rest of the tinycc code.

Thanks,

--- grischka

A

On Sun, Sep 10, 2017 at 1:36 AM, Andrei Warkentin <
address@hidden> 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 <address@hidden> написал(а):

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 <
address@hidden> написал(а):
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 <address@hidden> 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
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
_______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

--
A
------------------------------------------------------------
------------
_______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




------------------------------------------------------------------------

_______________________________________________
Tinycc-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]