What does dir in arch/<dir> mean in musl?

What does dir in arch/<dir> mean in musl?

[Anthony G. Basile]

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.

Contrast this to what the linux kernel does where we see:

$ ls /usr/src/linux/arch/
Kconfig  arm64     cris     m32r        mips      powerpc  sparc      x86
alpha    avr32     frv      m68k        mn10300   s390     tile       xtensa
arc      blackfin  hexagon  metag       openrisc  score    um
arm      c6x       ia64     microblaze  parisc    sh       unicore32


There arch/x86 contains both 64-bit and 32-bit ISAs and ABIs and one 
further specifies the arch with ARCH=x86_64 or ARCH=i686.   However, the 
headers for each of the arch/<dirs> are identical. eg ARCH=x86_64 make 
install_headers is the same as ARCH=x86 make install_headers.

So how are we to understand LDSO_ARCH?  I'm going to be writing a bash 
ldconfig which will manage paths in /etc/${LDSO_ARCH%so.1}path the way 
it does on glibc/uclibc for /etc/ld.so.cache.  It would be nice to avoid 
bad assumptions up front.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: What does dir in arch/<dir> mean in musl?

[Rich Felker]

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

Re: What does dir in arch/<dir> mean in musl?

[Wermut]

There are at least two different ldconfig like scripts for musl found
in Alpine Linux and Debian that you can possibly take for reference.

Alpine Linux: http://git.alpinelinux.org/cgit/aports/tree/main/musl/ldconfig

Debian: https://github.com/wermut/musl/blob/master/debian/scripts/ld-musl-config


On Thu, Nov 6, 2014 at 4:38 PM, Rich Felker <dalias@libc.org> wrote:
> 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