mbox series

[ARM/FDPIC,0/4] FDPIC ABI for ARM

Message ID 20180406151752.10854-1-christophe.lyon@st.com
Headers show
Series FDPIC ABI for ARM | expand

Message

Christophe Lyon April 6, 2018, 3:17 p.m. UTC
Hello,

This patch series implements the QEMU contribution of the FDPIC
ABI for ARM targets.

This ABI enables to run Linux on ARM MMU-less cores and supports
shared libraries to reduce the memory footprint.

Without MMU, text and data segment relative distances are different
from one process to another, hence the need for a dedicated FDPIC
register holding the start address of the data segment. One of the
side effects is that function pointers require two words to be
represented: the address of the code, and the data segment start
address. These two words are designated as "Function Descriptor",
hence the "FD PIC" name.

On ARM, the FDPIC register is r9 [3].

This work was developed some time ago by STMicroelectronics, and was
presented during Linaro Connect SFO15 (September 2015). You can watch
the discussion and read the slides [1].
This presentation was related to the toolchain published on github [2],
which is based on binutils-2.22, gcc-4.7, uclibc-0.9.33.2, gdb-7.5.1
and qemu-2.3.0, and for which pre-built binaries are available [2].

The ABI itself is described in details in [3].

Our Linux kernel patches have been updated and committed by Nicolas
Pitre (Linaro) in July 2017. They are required so that the loader is
able to handle this new file type. Indeed, the ELF files are tagged
with ELFOSABI_ARM_FDPIC. This new tag has been allocated by ARM, as
well as the new relocations involved.

This patch series has been rebased on top of QEMU from 2018-03-28.

I have also rebased the GCC patch series, but it is still WIP as
cleanup is still needed before I can request a review. It can be
useful to build a preview toolchain though, so my WIP branch is
available at [4].
To build such a toolchain, you'd also need to use my uClibc
branch [5].

I am currently working on updating the patches for the other toolchain
components, and will upstream them soon. This includes gcc, uclibc,
and gdb.

This series provides support for ARM v7 and later architectures and
has been used to run the GCC tests on arm-linux-gnueabi without
regression, as well as arm-linux-uclibceabi.

Are the QEMU patches OK for inclusion in master?

Thanks,

Christophe.


[1] http://connect.linaro.org/resource/sfo15/sfo15-406-arm-fdpic-toolset-kernel-libraries-for-cortex-m-cortex-r-mmuless-cores/
[2] https://github.com/mickael-guene/fdpic_manifest
[3] https://github.com/mickael-guene/fdpic_doc/blob/master/abi.txt
[4] https://git.linaro.org/people/christophe.lyon/gcc.git/log/?h=fdpic-upstream
[5] https://git.linaro.org/people/christophe.lyon/uclibc.git/log/?h=uClibc-0.9.33.2-fdpic-upstream

Christophe Lyon (4):
  linux-user: ARM-FDPIC: Add configure option to support loading of
    FDPIC binaries
  linux-user: ARM-FDPIC: Add support of FDPIC for ARM.
  linux-user: ARM-FDPIC: Add support for signals for FDPIC targets
  linux-user: ARM-FDPIC: Add arm get tls syscall support

 configure                       | 10 +++++
 include/elf.h                   |  1 +
 linux-user/arm/target_syscall.h |  1 +
 linux-user/elfload.c            | 35 ++++++++++++++++
 linux-user/main.c               |  8 ++++
 linux-user/qemu.h               |  3 ++
 linux-user/signal.c             | 91 +++++++++++++++++++++++++++++++++++++----
 target/arm/cpu.h                |  6 +++
 8 files changed, 147 insertions(+), 8 deletions(-)

-- 
2.6.3

Comments

Peter Maydell April 13, 2018, 3:18 p.m. UTC | #1
On 6 April 2018 at 16:17, Christophe Lyon <christophe.lyon@st.com> wrote:
> Hello,

>

> This patch series implements the QEMU contribution of the FDPIC

> ABI for ARM targets.


> I am currently working on updating the patches for the other toolchain

> components, and will upstream them soon. This includes gcc, uclibc,

> and gdb.

>

> This series provides support for ARM v7 and later architectures and

> has been used to run the GCC tests on arm-linux-gnueabi without

> regression, as well as arm-linux-uclibceabi.

>

> Are the QEMU patches OK for inclusion in master?


Hi; I've given the patches a quick look over for structural
issues, though I haven't looked too closely at the details.
I think that given that the support is in Linux master I'm
happy with it also going into QEMU.

NB that Laurent has some patchsets outstanding which rework
the linux-user code to split the per-architecture parts of
signal.c and main.c into per-architecture files rather than
having lots of ifdefs. Those will probably land early in the
2.13 cycle. I mention this just as a heads-up that at some point
you'll find yourself with a somewhat painful rebase.

PS: I'd recommend cc'ing the linux-user maintainers (listed in
the MAINTAINERS file) on your next version of this patchset.

thanks
-- PMM
Christophe Lyon April 16, 2018, 8:01 a.m. UTC | #2
On 13/04/2018 17:18, Peter Maydell wrote:
> On 6 April 2018 at 16:17, Christophe Lyon <christophe.lyon@st.com> wrote:

>> Hello,

>>

>> This patch series implements the QEMU contribution of the FDPIC

>> ABI for ARM targets.

> 

>> I am currently working on updating the patches for the other toolchain

>> components, and will upstream them soon. This includes gcc, uclibc,

>> and gdb.

>>

>> This series provides support for ARM v7 and later architectures and

>> has been used to run the GCC tests on arm-linux-gnueabi without

>> regression, as well as arm-linux-uclibceabi.

>>

>> Are the QEMU patches OK for inclusion in master?

> 

> Hi; I've given the patches a quick look over for structural

> issues, though I haven't looked too closely at the details.

> I think that given that the support is in Linux master I'm

> happy with it also going into QEMU.

> 

> NB that Laurent has some patchsets outstanding which rework

> the linux-user code to split the per-architecture parts of

> signal.c and main.c into per-architecture files rather than

> having lots of ifdefs. Those will probably land early in the

> 2.13 cycle. I mention this just as a heads-up that at some point

> you'll find yourself with a somewhat painful rebase.

> 


Thanks for the heads-up, I was unaware of that, and indeed I'd
rather avoid such a rebase.

> PS: I'd recommend cc'ing the linux-user maintainers (listed in

> the MAINTAINERS file) on your next version of this patchset.

> 

> thanks

> -- PMM

> .

>