This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: mips address+symbol issue.
- From: Richard Sandiford <rsandifo at redhat dot com>
- To: cgd at broadcom dot com
- Cc: gcc at gcc dot gnu dot org, binutils at sources dot redhat dot com
- Date: Sat, 24 Jan 2004 11:44:07 +0000
- Subject: Re: mips address+symbol issue.
- References: <yov5zncee5x0.fsf@ldt-sj3-010.sj.broadcom.com>
cgd@broadcom.com writes:
> I can think of several possible solutions here:
>
> (1) don't allow GCC to emit "dla sym+offset" for
> -mno-explicit-relocs, or maybe just for -mno-explicit-relocs
> and the ABIs which stuff 64-bit pointers into 32-bit object
> files.
>
> (2) make binutils emit long code sequences for sym + offset when
> assembling objects for an ABI which stuffs 64-bit pointers
> into 32-bit object files.
>
> (3) punt. (maybe even xfail the test for some MIPS targets w/
> -mno-explicit-relocs.)
>
> It seems to me that (2) is *probably* the right fix, but others'
> opinions would be appreciated. I think I'm OK with (3), too, but it
> might bite others down the road...
I guess the arguments in favour of (2) are that:
- It would work for older gccs. Some people refuse to use anything
newer than 2.95, for understandable reasons.
- It's counter-intuitive for "dla $2,a-2000000000" not to load the
address "a-2000000000"
But I agree with Ian (and you?) that pessimising the common case would
be a bad idea. Another downside is that it would make the macro longer
than it traditionally has been, which might lead to gcc (of whatever
vintage) generating out-of-range branches.
(I guess that's only a minor problem though, since the MIPS port
has traditionally been poor at predicting whether a branch will
be out of range.)
As you say, this doesn't happen for -mexplicit-relocs, but (as you
probably guessed) that's not because we're being smart. It's just
that we're not optimising this case particularly well. Explicit-reloc
code could in theory contain %his and %los with same sort of big offsets
that gas uses.
The patch to implement (1) would be:
@@ -918,8 +918,7 @@ mips_symbolic_constant_p (rtx x, enum mi
switch (*symbol_type)
{
case SYMBOL_GENERAL:
- /* %hi() and %lo() can handle anything. */
- return true;
+ return Pmode == SImode || ABI_HAS_64BIT_SYMBOLS;
case SYMBOL_SMALL_DATA:
/* Make sure that the offset refers to something within the
...which should fix both the explicit-reloc and macro cases. We could
do better by allowing offsets that refer to something in the underlying
object: I'll try to come up with a patch soon.
I'm reluctant to punt since the code is valid.
On a related note: what do folks think about the current default ABI for
mipsisa64-elf (i.e. the LP64 version of EABI64)? Is it really the best
choice? The use of 32-bit object files kind-of limits what you can with
64-bit addresses, and if you only need 32-bit addresses, you get much
better performance from the -mlong32 version.
I think we can choose whatever ABI we like for 3.4 since 3.3 used
the infamous, now-defunct "MEABI".
Richard