All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v1] Makefile: Don't generate position independent code
Date: Mon, 6 Aug 2018 19:32:28 +0200	[thread overview]
Message-ID: <a798596e-e813-438a-26e3-05e4c0331dfb@gmx.de> (raw)
In-Reply-To: <97deab69fc2705e77d5741a5431db29c9bcc3e2a.camel@linux.intel.com>

On 08/06/2018 07:11 PM, Andy Shevchenko wrote:
> On Mon, 2018-08-06 at 18:56 +0200, Heinrich Schuchardt wrote:
>> On 08/06/2018 06:00 PM, Andy Shevchenko wrote:
> 
>>> Fix all these by disabling PIE on Makefile level.
> 
>> With the patch building with gcc-8.1 works on i386.
> 
> Does it mean you are actually run it and it works?
> 
>>  But the interesting
>> question is whether the EFI subsystem will be able to relocate the
>> runtime code when the EFI service SetVirtualAddressMap() is called.
> 
> EFI code should have different CFLAGS I suppose.

This really depends on the architecture:

On RISC-V EFI specific flags are not defined.

On ARM
CFLAGS_NON_EFI := -fno-pic -ffixed-r9 -ffunction-sections -fdata-sections
CFLAGS_EFI := -fpic -fshort-wchar

On x86
ifeq ($(IS_32BIT),y)
CFLAGS_NON_EFI := -mregparm=3
endif
CFLAGS_EFI := -fpic -fshort-wchar

Do you know how -fpic and -fno-PIE work together when both are passed to
gcc?

CFLAGS_EFI is only used to compile standalone EFI executables like
helloworld.efi not the EFI runtime. See lib/efi_loader/Makefile.

Best regards

Hienrich

> 
>> Did you boot Linux with the patch via bootefi and call any of the EFI
>> runtime services from Linux?
> 
> Nope, I have no platform with UEFI to test.
> 
>> As you are changing this for all architectures this needs to be tested
>> on all (ARM, RISC-V, and x86) architectures supporting the EFI
>> subsystem.
> 
> Agree. Unfortunately I have almost none of them to play with.
> I leave this to others who able to confirm the patch works.
> 
> My understanding we need this anyway and if there are some problems, we
> need to fix them on individual basis.
> 

  reply	other threads:[~2018-08-06 17:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-06 16:00 [U-Boot] [PATCH v1] Makefile: Don't generate position independent code Andy Shevchenko
2018-08-06 16:56 ` Heinrich Schuchardt
2018-08-06 17:11   ` Andy Shevchenko
2018-08-06 17:32     ` Heinrich Schuchardt [this message]
2018-08-06 18:55       ` Andy Shevchenko
2018-08-06 19:40         ` Heinrich Schuchardt
2018-08-06 19:49           ` Andy Shevchenko
2018-08-09  9:43             ` Andy Shevchenko
2018-08-09  9:54               ` Bin Meng
2018-08-09 12:25                 ` Heinrich Schuchardt
2018-08-09 13:07                   ` Andy Shevchenko
2018-08-10  6:04                     ` Bin Meng
2018-09-02 23:50                       ` Simon Glass
2018-09-03  7:57                         ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a798596e-e813-438a-26e3-05e4c0331dfb@gmx.de \
    --to=xypron.glpk@gmx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.