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


"Richard Sandiford" <r.sandiford@redhat.com> writes:
> 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?

With the correct value, yes.

(For the case that got my attention, the issue was that the value was
incorrect.  If you remove the pcrel check i mentioned, then the value
becomes correct and you've got a working relocation against the global
symbol.  But who knows what it does to other pc-relative relocations?)


> 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.

Right.  I certainly don't understand this code, and I really prefer to
avoid tweaking code that I don't understand.

That's why I was planning to send a query off to the list.


> > > 	  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.

No.  I don't think i've ever seen the case where it would get into
that code path previously, for these relocations.


Lack of explanation is bad, yes.

Further, I'm not aware of any actual documentation on the PC-relative
relocations which are GNU extensions.

And (this is my fault) i've not really looked into the documentation
on the standard(?) PC-relative relocations, so I don't know when
they'd be generated to begin with or what exactly is expected of their
contents.

And finally, there's no testsuite coverage for basically any of them
except in the MIPS ECOFF tests -- which are broken and to which this
code doesn't apply anyway -- and the empic.s code which avoids testing
the one particular case that blew my code up.  8-(



chris


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