Re: More issues with the lsparc 64 bit stuff vs. other 64 bit archs in ldconfig/ld.so
On Wed, May 03, 2000 at 02:27:21PM -0400, David Huggins-Daines wrote:
> Well, I didn't even get to file a bug report and patch to ld.so before
> the new package was uploaded, and I spent several hours today tracking
> the problem, too. I guess I should get into the habit of tracking
> incoming for this sort of thing. It sure would be nice if (a) the BTS
> were faster, and (b) people would copy bug reports to the appropriate
> mailing lists so as to avoid duplication of effort.
>
> Anyway, regarding the LIB_ELF64 flag:
>
> a) It's only relevant to architectures that have a single dynamic
> loader that handles both 32 and 64 bit libraries (currently Sparc,
> maybe also PowerPC in the future, but definitely not Alpha or
> IA-64, ever)
sparc has seperate dynamic loaders for 32 and 64 bit code. AFAIK, you
can't load 64bit from a 32bit program, atleast not on sparc. Which is why
we have gotten Wichert to use objdump (and hopefully soon I can convert
him to readelf) in order to get library deps for dpkg-shlibdeps.
> b) It's not handled at all by the current ld-linux.so code. In fact,
> ld-linux.so has LIB_ELF and LIB_ELF_LIBC6 as magic numbers in its
> cache searching code (line 203,
> glibc-2.1.3/sysdeps/generic/dl-cache.c in the glibc source tree):
>
> if ((flags == 1 || flags == 3)
> && cache->libs[middle].value < cachesize - sizeof *cache)
This is completely different from glibc 2.2 CVS. Debian/SPARC wont be
using 64bit until 2.2 is released, so I suggest checking into that. From
elf/elf.h in glibc CVS:
#define ELFCLASS32 1 /* 32-bit objects */
#define ELFCLASS64 2 /* 64-bit objects */
This appears to be pretty generic (and further down there are SPARC
specific things). I'm not too familiar with this, so I'm not sure I'm on
the same track as you are.
> c) We have a patch for our libc on Sparc that has its own version of
> ldconfig, and this version of ldconfig uses a *different* flag to
> indicate ELF64 libraries (debian/patches/ldconfig.dpatch in the
> glibc source tree):
>
> +#define FLAG_ANY -1
> +#define FLAG_TYPE_MASK 0x00ff
> +#define FLAG_LIBC4 0x0000
> +#define FLAG_ELF 0x0001
> +#define FLAG_ELF_LIBC5 0x0002
> +#define FLAG_ELF_LIBC6 0x0003
> +#define FLAG_REQUIRED_MASK 0xff00
> +#define FLAG_SPARC_LIB64 0x0100
> ^^^^^^
>
> It would be nice to have some consistency between the various things
> that read and write the ld.so.cache (and no more magic numbers). The
> way that ldconfig.dpatch does things looks to be more correct to me,
> but it also constitutes a backwards-incompatible change to the cache
> format and so not only do we have to coordinate a fix to glibc but
> also the upgrade needs to be handled carefully.
Is this even used? Did you check that Joel was actually applying the patch
in the rules file? I know he has some stubs for 64bit sparc, but none of
it is being used yet, AFAIK. Also note that Debian/SPARC currently has 0
64bit support in userspace, so the cache wont be non-compatible, because
there should be 0 entries anyway. Plus, the ldconfig on Debian systems
still comes from ldso package, so glibc's patches shouldn't matter.
> The Sparc people should probably sit down and figure out a good way to
> do all this that won't break other archs.
I haven't looked at what is done for alpha, powerpc, or ia64, but I don't
see anything that is specific to sparc in the way it handles 32/64 bit
hybrid caches in glibc 2.2 CVS.
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bcollins@linux.com '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: