This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
MIPS16: AS wouldn't assemble gcc output.
- To: Dmitri Makarov <dim at windriver dot com>
- Subject: MIPS16: AS wouldn't assemble gcc output.
- From: Ian Lance Taylor <ian at zembu dot com>
- Date: 2 Mar 2000 20:27:03 -0500
- CC: binutils at sourceware dot cygnus dot com, gcc at gcc dot gnu dot org, dim at mail dot wrs dot com
From: Dmitri Makarov <dim@windriver.com>
Date: Thu, 2 Mar 2000 17:04:16 -0800 (PST)
The call to __assert is generated to be:
$LC21:
.ascii "Assertion failed: i<(size_t)N, file "
.ascii "tbitvec.h, line 142\n\000"
.align 2
............................................
.size __cl__t9RWTBitVec1i17Ui,$Lfe15-__cl__t9RWTBitVec1i17Ui
.section .gnu.linkonce.t.__vc__t9RWTBitVec1i17Ui,"ax",@progbits
.align 2
.weak __vc__t9RWTBitVec1i17Ui
.type __vc__t9RWTBitVec1i17Ui,@function
.ent __vc__t9RWTBitVec1i17Ui
__vc__t9RWTBitVec1i17Ui:
.frame $17,16,$31 # vars= 0, regs= 3/0, args= 16, extra= 0
.mask 0x80030000,-24
.fmask 0x00000000,0
addu $sp,$sp,-32
.............................................
$L396:
la $4,$LC21 <---------- ERROR
jal __assert
AS gives the error: Error: unsupported PC relative reference to
different section
The reason: $LC21 and la $4,$LC21 are in different sections. Comment
in gas/config/tc-mips.c says, that:
/* FIXME: We should support this, and let the linker
catch branches and loads that are out of range. */
as_bad_where (fragp->fr_file, fragp->fr_line,
_("unsupported PC relative reference to different section"));
LA $4, $LC21 isn't really a PC rel. load from different section...
Anyway, my question is anybody working on this or can someone give me
a hint on how this should be fixed, before I dive in GAS intricacies?
Actually, it really is a PC relative load from a different section.
The instruction is in the section
.gnu.linkonce.t.__vc__t9RWTBitVec1i17Ui
I don't know what the section the string is in.
gcc is supposed to avoid this. It is supposed to put the string
constant in the same section as the function. I'm not sure why that
isn't working in your case.
As the assembler comment suggests, it would be possible to simply emit
the relocation, and let the linker fail if the symbol turns out to be
out of range. However, the compiler should still avoid it.
I think that emitting the relocation would require inventing a new
relocation, since I don't think there is one for a mips16 PC relative
reference. The mips16 uses a weird instruction syntax, and
R_MIPS_PC16 would not be right. Support for this new relocation would
have to be added to gas and to BFD.
Ian