public inbox for
 help / color / mirror / Atom feed
From: Fangrui Song <>
To: Xi Ruoyao <>
Cc: WANG Xuerui <>,
	liuzhensong <>,,
Subject: Re: [PATCH v2] LoongArch: Set e_flags to 0x40 of ELF while using new relocations.
Date: Tue, 27 Sep 2022 09:49:33 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 2022-09-25, Xi Ruoyao wrote:
>On Sun, 2022-09-25 at 16:28 +0800, WANG Xuerui wrote:
>> > +
>> > +         if (elf_elfheader (output_bfd)->e_ident[EI_CLASS] == ELFCLASS32)
>> >             interpreter = "/lib32/";
>> > -         else if (EF_LOONGARCH_IS_LP64 (flags))
>> > +         else if (elf_elfheader (output_bfd)->e_ident[EI_CLASS] == ELFCLASS64)
>> >             interpreter = "/lib64/";
>> >           else
>> >             interpreter = "/lib/";
>> > +
>> Wait what, are we still carrying the old-world defaults for the
>> interpreter path here? I know it's harmless because in fact it gets
>> overridden by gcc and glibc, but I'd suggest fixing it in a separate
>> patch later for consistency.
>It seems not easy to make a "correct" default...  /lib64/ld-linux-
> will be incorrect for a musl-based target.  Maybe
>we can assume Glibc is used because we are the *GNU* linker anyway...
>/* snip */

For all other architectures, the default dynamic linker is just not
useful. (ld.lld encodes no string at all.) Ideally this should be empty,
but if an empty interpreter string uses a behavior similar to --no-dynamic-linker,
use an arbitrary dummy string.

>> I'd bikeshed a little and suggest "EF_LOONGARCH_OBJABI_foo" because
>> it's actually "ELF object file ABI v1" and not "ELF ABI object v1".
>In the doc we say "the ABI version of an ELF object", IMO it's a little
>misleading (can trick people to believe it could be used to distinguish
>old and new world).  From Wikipedia:
>   In computer software, an application binary interface (ABI) is an
>   interface between two binary program modules.
>I'm not sure if the (non-dynamic) relocation types belongs to the concept
>of ABI: the linker treats relocatable object files as an input (like how
>"vim" treats a text file), instead of a program module.  But I can't come
>up with a better terminology for now...
>Xi Ruoyao <>
>School of Aerospace Science and Technology, Xidian University

  reply	other threads:[~2022-09-27 16:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-21  1:17 liuzhensong
2022-09-25  8:28 ` WANG Xuerui
2022-09-25  9:22   ` Xi Ruoyao
2022-09-27 16:49     ` Fangrui Song [this message]
2022-09-27  2:11   ` liuzhensong

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* 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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).