This is the mail archive of the binutils@sources.redhat.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]
Other format: [Raw text]

Re: On resolving the MIPS gas branch reloc issue


Alexandre Oliva wrote:
> On Feb 26, 2003, Thiemo Seufer <ica2_ts at csv dot ica dot uni-stuttgart dot de> wrote:
> 
> > The Embedded PIC ABI did something similiar earlier but with a GNU
> > extension relocation. To keep compatible to it, we need now one new
> > BFD_RELOC_MIPSEMB_16_PCREL_S2 bfd reloc, because BFD has no way to
> > find out the ABI early enough.
> 
> Have you tested this heavily with n32 and/or n64?

I did some successful tests, mainly for n64 non-PIC, but nothing
really complicated WRT branch relocations. The testsuite worked,
too, but OTOH there still aren't NewaBI tests.

> I ran into all
> sorts of trouble because of weirdnesses

I guess you are talking about mips*-linux, not mips*-irix.
The IRIX linker is likely to have troubles with R_MIPS_PC16 relocs.

> such as the code next to the
> following comments in gas/config/tc-mips.c:
> 
> 	      /* In this case, the bfd_install_relocation routine will
> 		 incorrectly add the symbol value back in.  We just want
> 		 the addend to appear in the object file.
> 
> 		 howto->pcrel_offset is added for R_MIPS_PC16, which is
> 		 generated for code like
> 
> 		 	globl g1 .text
> 			.text
> 			.space 20
> 		 g1:
> 		 x:
> 		 	bal g1
> 	       */
> 
> 
> 	      /* Make sure the addend is still non-zero.  If it became zero
> 		 after the last operation, set it to a spurious value and
> 		 subtract the same value from the object file's contents.  */
> 
> 
>       /* This code was generated using trial and error and so is
> 	 fragile and not trustworthy.  If you change it, you should
> 	 rerun the elf-rel, elf-rel2, and empic testcases and ensure
> 	 they still pass.  */
> 
> 	  /* BFD's REL handling, for MIPS, is _very_ weird.
> 	     This gives the right results, but it can't possibly
> 	     be the way things are supposed to work.  */
> 
> 
>       /* If 'value' is zero, the remaining reloc code won't actually
> 	 do the store, so it must be done here.  This is probably
> 	 a bug somewhere.  */
> 
> 
> All of these chunks assume REL relocations, and since n32 and n64 use
> RELA, there's no way to generate appropriate relocations for certain
> border values that trigger special conditions in the generic
> relocation handling code.  I tried very hard to fix them, but failed.
> I wish the fix was this simple :-(

Can you send me some testcases for these? I'd like to look into it.

> Perhaps we should just go with branches to symbols in the same
> sections for now?  Do you still have patch that you send me the other
> day to that effect handy?  Perhaps you could propose it here as well?

IMHO it's better to keep the current version and fix NewABI.
I'll propose the other patch only as a last resort thing.


Thiemo


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