This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

MIPS16: AS wouldn't assemble gcc output.


   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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]