[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140617153903.GH179@brightrain.aerifal.cx>
Date: Tue, 17 Jun 2014 11:39:03 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: arch-specific reloc.h inconsistencies (bugs?)
On Tue, Jun 17, 2014 at 01:01:32AM -0400, Rich Felker wrote:
> 1. powerpc and sh use RELA (addend in the reloc structure rather than
> inline at the address to be relocated), but the addend is ignored
> and an inline addend is instead read for thread-pointer-relative
> (TPREL) relocations. On sh this also happens for DTPMOD and DTPOFF
> relocations. For DTPMOD that's definitely a bug since an addend
> makes no sense for these whatsoever, but I'm not sure about the
> others. It might be a "historical bug" that has to be duplicated
> for compatibility with toolchains that enshrined it, or it might
> just be a musl bug (likely due to copy-and-paste from other archs).
>
> 2. On sh, GLOB_DAT and JMP_SLOT relocations ignore the addend. This
> seems like it would give wrong results for things like:
> char *global2 = &global1[N];
Based on reading uClibc and glibc dynamic linker sources, these issues
seem to be bugs in musl.
I did however find what seems to be a related bug in glibc: when
processing R_SH_RELATIVE, rather than using the RELA or inline addend
conditionally based on whether the relocation is RELA-form, it uses
the RELA addend if it's nonzero and otherwise uses an inline addend.
In theory this could be a workaround for historical toolchain bugs
(storing an inline addend despite the ELF semantics requiring it to be
in the RELA structure) but I suspect it's just a bug that doesn't
trigger with real toolchains. uClibc does not have this behavior.
> 3. Also on sh, there's a strange REL32 relocation that applies
> base_addr as an addend to an expression which already contains a
> symbol value. This seems nonsensical to me just from a "units"
> perspective but maybe it's right since another address (the address
> to which the relocation is being supplied) is subtracted.
As far as I can tell, this is also a bug in musl. As I said it makes
no sense to me, and neither uClibc nor glibc is doing this.
So I'll fix these bugs first in the existing framework, then start on
refactoring. This way the refactoring should (at least mostly) avoid
functional changes.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
