public inbox for u-boot@lists.denx.de
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox