public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Sam Edwards <cfsworks@gmail.com>
To: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: u-boot@lists.denx.de, Heinrich Schuchardt <xypron.glpk@gmx.de>,
	Tom Rini <trini@konsulko.com>
Subject: Re: [RFC PATCH 07/10] arm: efi_loader: discard hash, unwind information
Date: Mon, 22 May 2023 13:25:50 -0600	[thread overview]
Message-ID: <31a43ffb-9aa6-d3f6-5cb5-781ea9e28e04@gmail.com> (raw)
In-Reply-To: <CAC_iWjLrATUMUfintFnrrUd537RmY85UFwOcYZj7-aeZ_bKUhQ@mail.gmail.com>

Hi Ilias,

On 5/22/23 01:00, Ilias Apalodimas wrote:
> The reason we end up with both hash and gnu.hash is because the hash
> style is set to 'both'.  Should we perhaps use (and strip) only one of
> them?

If we do keep one, it should probably be .hash -- see commit b02bfc4dfc.

I admit I'm completely mystified as to why we need the hash tables at 
all. The ELF spec says those are just for the dynamic linker, but 
neither the EFI code nor the self-relocating thunk require it, and I 
don't know of any target where the u-boot ELF itself is the shipped 
binary. For all I know, there never was a need to include .hash and 
Albert's commit fixed whatever problem he was facing only accidentally. 
Do you have any insights?

LLD's --hash-style option doesn't appear to have a "none" option or I'd 
just be making use of that here.

Cheers,
Sam

  reply	other threads:[~2023-05-22 19:25 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 [this message]
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
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=31a43ffb-9aa6-d3f6-5cb5-781ea9e28e04@gmail.com \
    --to=cfsworks@gmail.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.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