mips tls with -mlong64/-mgp32

[DJ Delorie]

> But the original patch was wrong.

I think the original patch was right (or at least right-ish), but
caused other functions to have mis-assumptions and thus become wrong.
We certainly *can* support offsetted TPREL and DTPREL symbols, as the
assembler, linker, and chip allow them.  Whether that causes other
functions to do the wrong thing *semantically* is a different issue.

Recall the function was mips_symbolic_constant_p().

> You can't assume anything +4 is valid.  It is OK in your particular
> case because the decl you're using it for is 8-byte aligned, but not
> all TLS data is 8-byte aligned.

Anything with lesser alignment could still be offset by 4 and still be
valid, assuming we don't care about "user stupidity" in addressing
beyond the end of memory.

Besides, why is this different than with non-tls symbols?
SYMBOL_SMALL_DATA allows for arbitrary offsets within an object, TLS
data is no different.  Perhaps we should figure out how to use
offset_within_block_p() ?

> I suppose that the m->o thing didn't work because the address isn't
> considered to be mode-dependent.  We should either make it mode-dependent,
> or check whether the offset is within the alignment of the SYMBOL_REF_DECL.
> The latter should be enough for TLS symbols, and is probably better.

Unfortunately, mips_symbolic_constant_p() doesn't know what type of
memory reference (or if there's a memory reference at all) will be
done.  No matter how we decide that a split is valid, we still need to
allow the offsetted tls symbol.