mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: What does dir in arch/<dir> mean in musl?
Date: Thu, 6 Nov 2014 10:38:59 -0500	[thread overview]
Message-ID: <20141106153859.GA22465@brightrain.aerifal.cx> (raw)
In-Reply-To: <545B6BDD.2030200@opensource.dyc.edu>

On Thu, Nov 06, 2014 at 07:38:53AM -0500, Anthony G. Basile wrote:
> Hi everyone,
> 
> In the context of integrating musl with gentoo, we have to deal with
> how we construct the link path file. So far we've been doing a
> variation of
> 
> LDSO_ARCH=$(basename /lib/ld-musl-*.so.1)
> cat << EOF > /etc/${LDSO_ARCH%so.1}path
> <paths>
> EOF
> 
> 
> where LDSO_ARCH is defined in arch/<dir>/reloc.h.  But what does
> <dir> mean in this case?  I know it *says* arch but it doesn't
> appear to be arches but rather an inconsistent combination of ISA +
> ABI.  Eg. x32 is an ABI which runs on 64-bit intel ISA, while x86_64
> is a different ABI on the same.  On the other hand all mips
> isas/abis/endians/floats are under arch/mips.

This is an area where existing practice differs a lot. For the kernel
folks, even 32- and 64-bit versions of a particular ISA are considered
the same arch. musl is on the opposite end of the spectrum, where
basic arch divisions cover both the ISA and how it's being used (you
can think of this as ABI). Here, x32 and x86_64 are separate archs, as
are powerpc/powerpc64, mips/mipsn32/mips64, etc. (the latter are not
yet supported though). musl also has subarchs for minor variants;
these should be considered an implementation detail. Examples are
armhf, mips-sf, mipsel, and so on. From your perspective, they're
distinct archs; the distinction between archs and subarchs is really
purely an implementation detail of musl's headers and build system.

If you don't want to hard-code a list of arch names, the easiest way
to get the right one would be to compile a dynamic linked program and
use readelf or objdump to read the PT_INTERP (dynamic linker) header.
The method you showed above will fail if more than one dynamic linker
is installed, which could easily be the case if the user is running
binaries for multiple ABI variants on a given piece of hardware or
using qemu to run foreign binaries. The method I described necessarily
tells you the one connected to the compiler you're using.

Rich


  reply	other threads:[~2014-11-06 15:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-06 12:38 Anthony G. Basile
2014-11-06 15:38 ` Rich Felker [this message]
2014-11-06 17:34   ` Wermut

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=20141106153859.GA22465@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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 NNTP newsgroup(s).