All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] quagga: disable PIE on ARC
Date: Fri, 10 Jul 2015 08:12:06 +0000	[thread overview]
Message-ID: <1436515926.2800.26.camel@synopsys.com> (raw)
In-Reply-To: <20150710084455.3462000c@free-electrons.com>

Hi Thomas, Arnout,

On Fri, 2015-07-10 at 08:44 +0200, Thomas Petazzoni wrote:
> Arnout, Alexey,
> 
> On Thu, 9 Jul 2015 23:30:14 +0200, Arnout Vandecappelle wrote:
> > On 07/09/15 12:00, Alexey Brodkin wrote:
> > > Even though ARC gcc understands "-pie" option and attempts to generate
> > > PIE binaries as of today PIE is not really supported for user-space
> > > applications.
> > 
> >  Wouldn't it be better then if we would patch gcc to remove the -pie option?
> > That removes all these special cases in one fell swoop, and is much easier to
> > un-disable once PIE _is_ supported for ARC gcc.
> 
> It would indeed be a lot better.

I would agree with that proposal but... TL;DR below :)

Actually at the moment the only real "user" of PIE (in case of ARC)
is U-Boot. U-Boot (by its generic design which is architecture independent)
does "self-relocation" on early boot.

Scenario is simple.

We assume that U-Boot executable is located in ROM after power-up
and what's more important has access to very limited amount of RAM.

For example on Intel machines U-Boot uses locked cache as pre-relocation RAM.
Other examples could be on-chip RAM etc.

So what happens U-Boot does very-very basic initialization including say DDR
init and then U-Boot copies itself in DDR (in the very end of available
memory so it may then load something useful in the beginning of DDR for
example Linux kernel or other executable).

But to have an ability to execute relocated/moved code and access data
that was also moved it's required to fixup locations of functions and data
units that are accessed directly (i.e. by its address compared to relative
offset from current location).

Note that U-Boot copies all sections be it .data, .text,
.rel etc. except .bss which is supposed to be used only after relocation
and so its area just gets zeroed during "relocation".

And what happens U-Boot is linked with "-pae" which leads to a fact
that executable contains a special section called usually .rel or .rela
where resides information about all directly addressed units.

During relocation U-Boot once all required sections were copied from
flash/ROM to DDR reads data from .rel/.rela updates all directly used
addresses (by simple addition of offset between address in flash/ROM and
new location in DDR).

What is important PIC (Position-Independent Code) is not enough here
because it only cares about code but not data. While PIE
(Position-Independent Executable) cares about both code and data.

Now we have U-Boot for ARC and it could be built from any recent upstream
U-Boot release. And we want people to have ability to build U-Boot with
Buildroot.

But as we know Buildroot builds only one toolchain for all purposes.
Even for building Linux kernel or U-Boot while those are bare-metal
executables compared to user-space apps that are normally built by
*libc-toolchain.

In other words if we disable PIE in Buildroot's toolchain there will be
no way to build U-Boot for ARC. And that's not what we want.

Note that U-Boot needs PIE not only on ARC but on x86, ARM and MIPS.
So that's not unique "feature" or ARC. Some arches still use PIC in
U-Boot but that causes problems here and there, requiring to patch
offsets manually in each and every driver etc instead of using gcc,
grep for CONFIG_NEEDS_MANUAL_RELOC if of any interest :)

Hopefully my explanation makes some sense.

If you guys have any thought on how to solve that problem better please
shout.

-Alexey

  reply	other threads:[~2015-07-10  8:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-09 10:00 [Buildroot] [PATCH] quagga: disable PIE on ARC Alexey Brodkin
2015-07-09 20:14 ` Thomas Petazzoni
2015-07-09 21:30 ` Arnout Vandecappelle
2015-07-10  6:44   ` Thomas Petazzoni
2015-07-10  8:12     ` Alexey Brodkin [this message]
2015-07-10 10:08       ` Arnout Vandecappelle
2015-07-10 11:28         ` Alexey Brodkin
2015-07-10 12:21           ` Arnout Vandecappelle
2015-07-10 13:08             ` Thomas Petazzoni
2015-07-10 22:05               ` Arnout Vandecappelle

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=1436515926.2800.26.camel@synopsys.com \
    --to=alexey.brodkin@synopsys.com \
    --cc=buildroot@busybox.net \
    /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.