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]

Re: More problems with MIPS gas relocations


cgd@broadcom.com writes:

> > The same hunk of code causes the following to be misassembled, but
> > for different reasons:
> 
> Is that due to a change in the code made over the last few months, or
> is it as "historical issue"?

Ah!  I didn't think a bug like that would go undetected for long.

You're right, it was that patch that changed things.  The relocs used to be
against the .sdata section and things worked fine.  But making the reloc be
against a global symbol should work too, right?

On the other hand, this ELF hack is so horribly fragile that it might not
be a good idea to use it more often unless we really have to.

> [snip empic example]

Yikes!

> I figure, the old way was correct, or, if the new way of handling
> external symbols really is correct, the reloc against the external
> sybol with a -1 (0xffff) value in the instruction also works.  I
> accomplished that by changing the code:
> 
> 
> > 	  || (symbol_used_in_reloc_p (fixP->fx_addsy)
> > 	      && (((bfd_get_section_flags (stdoutput,
> > 					   S_GET_SEGMENT (fixP->fx_addsy))
> > 		    & SEC_LINK_ONCE) != 0)
> > 		  || !strncmp (segment_name (S_GET_SEGMENT (fixP->fx_addsy)),
> > 			       ".gnu.linkonce",
> > 			       sizeof (".gnu.linkonce") - 1))))
> > 
> > 	{
> > 	  valueT symval = S_GET_VALUE (fixP->fx_addsy);
> > 	  value -= symval;
> > 	  if (value != 0 && ! fixP->fx_pcrel)
> 
> 			    ^^^^^^^^^^^^^^^^
> 
> to omit that check.

Any idea why it's there now?  The "value != 0" bit seems to be anticipating
the condition in bfd_elf_generic_reloc.  But I can't figure out what the
pcrel check is there for.  It's bad enough having a hack like this OBJ_ELF
thing in the first place.  Having one without any kind of explanation just
makes things worse.

> I've not looked to understand when exactly OBJ_ELF is defined, but for
> the last two, I wonder if they should also check (OUTPUT_FLAVOR ==
> bfd_target_elf_flavour).  E.g. other code in mips_fix_adjustable()
> that's #ifdef'd under OBJ_ELF checks that ELF is being output... so
> either the mips_fix_adjustable change in the patch below changed
> behaviour for non-ELF, or the other bit of mips_fix_adjustable is
> wrong.  8-)

Yup, I wondered about that too.  

Richard


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