All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
To: Sam Edwards <cfsworks@gmail.com>
Cc: u-boot@lists.denx.de, Albert ARIBAUD <albert.u.boot@aribaud.net>,
	Alper Nebi Yasak <alpernebiyasak@gmail.com>,
	Andrew Scull <ascull@google.com>,
	Kever Yang <kever.yang@rock-chips.com>,
	Michal Simek <michal.simek@amd.com>,
	Nathan Barrett-Morrison <nathan.morrison@timesys.com>,
	Peng Fan <peng.fan@nxp.com>, Philip Oberfichtner <pro@denx.de>,
	Philipp Tomsich <philipp.tomsich@vrull.eu>,
	Simon Glass <sjg@chromium.org>, Tom Rini <trini@konsulko.com>
Subject: Re: [RFC PATCH 10/10] arm: migrate away from sections.c
Date: Tue, 23 May 2023 09:56:30 +0300	[thread overview]
Message-ID: <ZGxjnpPQJVZkqDLW@hera> (raw)
In-Reply-To: <20230520205547.1009254-11-CFSworks@gmail.com>

On Sat, May 20, 2023 at 02:55:47PM -0600, Sam Edwards wrote:
> This patch effectively reverts 3ebd1cbc49f0005092d69cf0d9a6e64d7a1c300b.

Also 47bd65ef057fb71b02b32741d5cfcaf03e2f0918 ?

>
> The approach taken in that commit was to have the section-marking
> symbols generated into empty sections by the compiler, for the linker
> script to include at the correct location. The rationale was that at
> the time, the linker considered linker-assigned symbols to be dynamic
> when they were in PIC (PIEs or shared libraries), which meant they were
> represented at runtime by a R_ARM_ABS32 relocation (by symbol name)
> rather than by M_ARM_RELATIVE.
>
> That commit landed in March 2013, but GNU ld later changed its behavior
> on 2016-02-23 to default linker-assigned symbols to dynamic only in
> shared libraries (not PIE), so this approach is unnecessary.
>
> I am removing it, because:
> 1) It required keeping sections.c in sync with multiple linker scripts.
> 2) It added complexity to the linker scripts, making them less readable.
> 3) It added unnecessary sections to the output, which can't be merged
>    because the sections are sometimes of different types.
> 4) The linker may insert sections not explicitly named in the script
>    somewhere between explicit sections; having the marker symbols
>    outside of the sections they were marking meant the markers could
>    end up with an unintended section inserted within that region.
>
> Signed-off-by: Sam Edwards <CFSworks@gmail.com>
> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
>

 Thanks
 /Ilias

  reply	other threads:[~2023-05-23  6:56 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-20 20:55 [RFC PATCH 00/10] Improve ARM target's support for LLVM toolchain Sam Edwards
2023-05-20 20:55 ` [RFC PATCH 01/10] makefile: Fix symbol typo in binary_size_check Sam Edwards
2023-05-20 20:55 ` [RFC PATCH 02/10] arm: set alignment properly for asm funcs Sam Edwards
2023-05-20 20:55 ` [RFC PATCH 03/10] arm: exclude eabi_compat from LTO Sam Edwards
2023-05-20 20:55 ` [RFC PATCH 04/10] arm: add __aeabi_memclr in eabi_compat Sam Edwards
2023-05-20 20:55 ` [RFC PATCH 05/10] arm: add aligned-memory aliases to eabi_compat Sam Edwards
2023-05-20 20:55 ` [RFC PATCH 06/10] arm: discard .gnu.version* sections Sam Edwards
2023-05-20 20:55 ` [RFC PATCH 07/10] arm: efi_loader: discard hash, unwind information Sam Edwards
2023-05-22  7:00   ` Ilias Apalodimas
2023-05-22 19:25     ` Sam Edwards
2023-05-22 20:28       ` Ilias Apalodimas
2023-05-23  5:08       ` Heinrich Schuchardt
2023-05-20 20:55 ` [RFC PATCH 08/10] arm: efi_loader: move .dynamic out of .text in EFI Sam Edwards
2023-05-22  7:30   ` Ilias Apalodimas
2023-05-22  8:10   ` Heinrich Schuchardt
2023-05-22 17:13     ` Sam Edwards
2023-05-20 20:55 ` [RFC PATCH 09/10] arm: discard all .dyn* sections Sam Edwards
2023-05-20 20:55 ` [RFC PATCH 10/10] arm: migrate away from sections.c Sam Edwards
2023-05-23  6:56   ` Ilias Apalodimas [this message]
2023-05-21  4:26 ` [RFC PATCH 00/10] Improve ARM target's support for LLVM toolchain Heinrich Schuchardt
2023-05-21  4:59   ` Sam Edwards
2023-05-22  6:52     ` Ilias Apalodimas
2023-05-22 19:37       ` Sam Edwards
2023-05-22 20:15         ` Heinrich Schuchardt
2023-05-23  6:54         ` Ilias Apalodimas
2023-05-22 10:39     ` Michal Simek
2023-05-22 15:30       ` Tom Rini
2023-05-22 19:59         ` Sam Edwards
2023-05-22 21:13           ` Tom Rini

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=ZGxjnpPQJVZkqDLW@hera \
    --to=ilias.apalodimas@linaro.org \
    --cc=albert.u.boot@aribaud.net \
    --cc=alpernebiyasak@gmail.com \
    --cc=ascull@google.com \
    --cc=cfsworks@gmail.com \
    --cc=kever.yang@rock-chips.com \
    --cc=michal.simek@amd.com \
    --cc=nathan.morrison@timesys.com \
    --cc=peng.fan@nxp.com \
    --cc=philipp.tomsich@vrull.eu \
    --cc=pro@denx.de \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --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.