public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* [RFC] Allow user to filter symbols in the object file produced by --out-implib
@ 2021-12-03 14:52 Torbjorn SVENSSON
  2021-12-10 13:00 ` Torbjorn SVENSSON
  2021-12-15 17:25 ` Nick Clifton
  0 siblings, 2 replies; 4+ messages in thread
From: Torbjorn SVENSSON @ 2021-12-03 14:52 UTC (permalink / raw)
  To: binutils; +Cc: Christophe LYON

Hello,


When working with an ARM Cortex-M33 with TrustZone, the usual way is to have one application for the secure context and another application for the non-secure context.

When linking a secure application for ARM Cortex-M33 with TrustZone, the "--cmse-implib" and "--out-implib" linker flags are used to generate an object file where the locations of the non-secure callable functions are shared.
When linking the non-secure application for the ARM Cortex-M33 with TrustZone, the object file with the non-secure callable functions is used as an ordinary object file.

This works fine and the implib will only contain functions marked with "__attribute((cmse_nonsecure_entry))".

Let's consider the use case where the embedded target contains both an user application and a bootloader. The bootloader may provide some functions that should be accessible by the user application.
One way to solve this is to put the functions at a fixed location in the bootloader linker script and then hard-code that address in the user application to make it callable.
Another way would be to rely on the implib functionality to automatically export the location of the symbol in a way that can be "imported" when linking the user application. In this sense, the implib will be the "interface" between the 2 applications.

If the bootloader would use the "--out-implib" flag, then there would be a lot more symbols exposed than the symbols that were intended to be shared between the bootloader application and the user application.
If the same symbol name exists in both the bootloader codebase and the user application codebase, it's even likely that there will be link error due to multiple definitions.

So, what I think could be beneficial for the general ld is to let the user define a set of symbols to expose in the implib without affecting the main output of the linker step (the ELF file).

I would like to get your opinion on this topic before I start implementing something like this.
Does it make sense to do this or is there some other way to reduce the number of symbols exposed in the implib without affecting the ELF file?


Kind regards,
Torbjörn

^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: [RFC] Allow user to filter symbols in the object file produced by --out-implib
  2021-12-03 14:52 [RFC] Allow user to filter symbols in the object file produced by --out-implib Torbjorn SVENSSON
@ 2021-12-10 13:00 ` Torbjorn SVENSSON
  2021-12-15 17:25 ` Nick Clifton
  1 sibling, 0 replies; 4+ messages in thread
From: Torbjorn SVENSSON @ 2021-12-10 13:00 UTC (permalink / raw)
  To: binutils; +Cc: Christophe LYON

Ping?

-----Original Message-----
From: Binutils <binutils-bounces+torbjorn.svensson=st.com@sourceware.org> On Behalf Of Torbjorn SVENSSON via Binutils
Sent: den 3 december 2021 15:53
To: binutils@sourceware.org
Cc: Christophe LYON <christophe.lyon@st.com>
Subject: [RFC] Allow user to filter symbols in the object file produced by --out-implib

Hello,


When working with an ARM Cortex-M33 with TrustZone, the usual way is to have one application for the secure context and another application for the non-secure context.

When linking a secure application for ARM Cortex-M33 with TrustZone, the "--cmse-implib" and "--out-implib" linker flags are used to generate an object file where the locations of the non-secure callable functions are shared.
When linking the non-secure application for the ARM Cortex-M33 with TrustZone, the object file with the non-secure callable functions is used as an ordinary object file.

This works fine and the implib will only contain functions marked with "__attribute((cmse_nonsecure_entry))".

Let's consider the use case where the embedded target contains both an user application and a bootloader. The bootloader may provide some functions that should be accessible by the user application.
One way to solve this is to put the functions at a fixed location in the bootloader linker script and then hard-code that address in the user application to make it callable.
Another way would be to rely on the implib functionality to automatically export the location of the symbol in a way that can be "imported" when linking the user application. In this sense, the implib will be the "interface" between the 2 applications.

If the bootloader would use the "--out-implib" flag, then there would be a lot more symbols exposed than the symbols that were intended to be shared between the bootloader application and the user application.
If the same symbol name exists in both the bootloader codebase and the user application codebase, it's even likely that there will be link error due to multiple definitions.

So, what I think could be beneficial for the general ld is to let the user define a set of symbols to expose in the implib without affecting the main output of the linker step (the ELF file).

I would like to get your opinion on this topic before I start implementing something like this.
Does it make sense to do this or is there some other way to reduce the number of symbols exposed in the implib without affecting the ELF file?


Kind regards,
Torbjörn

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [RFC] Allow user to filter symbols in the object file produced by --out-implib
  2021-12-03 14:52 [RFC] Allow user to filter symbols in the object file produced by --out-implib Torbjorn SVENSSON
  2021-12-10 13:00 ` Torbjorn SVENSSON
@ 2021-12-15 17:25 ` Nick Clifton
  2021-12-22  9:24   ` Torbjorn SVENSSON
  1 sibling, 1 reply; 4+ messages in thread
From: Nick Clifton @ 2021-12-15 17:25 UTC (permalink / raw)
  To: Torbjorn SVENSSON; +Cc: Christophe LYON, Binutils

Hi Torbjorn,

> If the bootloader would use the "--out-implib" flag, then there would be a lot more symbols exposed than the symbols that were intended to be shared between the bootloader application and the user application.

> So, what I think could be beneficial for the general ld is to let the user define a set of symbols to expose in the implib without affecting the main output of the linker step (the ELF file).
> 
> I would like to get your opinion on this topic before I start implementing something like this.
> Does it make sense to do this or is there some other way to reduce the number of symbols exposed in the implib without affecting the ELF file?

Could you use objcopy's --keep-symbols option to take the
over populated out-implib file and just keep the symbols
that you wanted ?

If that will not work and you do want to implement a linker
enhancement then I think that you find it easier if you make
it ARM specific, rather than a general feature.  You could
probably implement a new option in ld/scripttempl/armelf.em
and process it in bfd/elf32-arm.c.

Cheers
   Nick


^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: [RFC] Allow user to filter symbols in the object file produced by --out-implib
  2021-12-15 17:25 ` Nick Clifton
@ 2021-12-22  9:24   ` Torbjorn SVENSSON
  0 siblings, 0 replies; 4+ messages in thread
From: Torbjorn SVENSSON @ 2021-12-22  9:24 UTC (permalink / raw)
  To: Nick Clifton; +Cc: Christophe LYON, Binutils

Hi Nick,

Sorry for top-posting, but Outlook do not have any good way of doing normal mail handling.

Regarding the objcopy --keep-symbols; this will only work on EXEC files. Running objcopy --keep-symbols on an object file just gives:

$ arm-none-eabi-objcopy --keep-symbols=foo.txt foo.o reduced.o
/usr/bin/arm-none-eabi-objcopy.exe: error: the input file 'foo.o' has no sections

$ arm-none-eabi-readelf -h foo.o
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          5236 (bytes into file)
  Flags:                             0x5000400, Version5 EABI, hard-float ABI
  Size of this header:               52 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           40 (bytes)
  Number of section headers:         4
  Section header string table index: 3


I'll give it a try over the coming weeks to implement a prototype that I will send to the list for review.

Kind regards,
Torbjörn


ST Restricted

-----Original Message-----
From: Nick Clifton <nickc@redhat.com> 
Sent: den 15 december 2021 18:26
To: Torbjorn SVENSSON <torbjorn.svensson@st.com>
Cc: Christophe LYON <christophe.lyon@st.com>; Binutils <binutils@sourceware.org>
Subject: Re: [RFC] Allow user to filter symbols in the object file produced by --out-implib

Hi Torbjorn,

> If the bootloader would use the "--out-implib" flag, then there would be a lot more symbols exposed than the symbols that were intended to be shared between the bootloader application and the user application.

> So, what I think could be beneficial for the general ld is to let the user define a set of symbols to expose in the implib without affecting the main output of the linker step (the ELF file).
> 
> I would like to get your opinion on this topic before I start implementing something like this.
> Does it make sense to do this or is there some other way to reduce the number of symbols exposed in the implib without affecting the ELF file?

Could you use objcopy's --keep-symbols option to take the
over populated out-implib file and just keep the symbols
that you wanted ?

If that will not work and you do want to implement a linker
enhancement then I think that you find it easier if you make
it ARM specific, rather than a general feature.  You could
probably implement a new option in ld/scripttempl/armelf.em
and process it in bfd/elf32-arm.c.

Cheers
   Nick

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-12-22  9:24 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-03 14:52 [RFC] Allow user to filter symbols in the object file produced by --out-implib Torbjorn SVENSSON
2021-12-10 13:00 ` Torbjorn SVENSSON
2021-12-15 17:25 ` Nick Clifton
2021-12-22  9:24   ` Torbjorn SVENSSON

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).