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]

Re: PATCH for 64-bit MIPS ELF buglets


   From: Mark Mitchell <mark@codesourcery.com>
   Date: Mon, 12 Jul 1999 12:46:25 -0700

   The loss of R_MIPS16_26/R_MIPS16_GPREL was an oversight on my part.  I
   fully intended to restore them, but forgot.  However, I cannot find
   any documentation on what these relocations do.  Can you point me at
   anything, other than the previous code?  If you cannot, I will try to
   decipher it, and make the right thing happen, but I would feel more
   comfortable working from documentation.

I'm afraid that there isn't any documentation on those relocations.  I
just wrote them so that they worked.  I can probably answer any
questions you have.

The mips16 jump instruction is weird because the address is stored in
a permuted format so that it can be picked up by the 16 bit
instruction decoder.

Some of the mips16 stub support seems to have disappeared as well.
That all needs to get restored too.

   You occasionally point out the obvious; I'm not clueless, just a bit
   new to binutils.  When big rewrites happen, things tend to get broken
   for a while; now that the rewriting is done, these things will get
   fixed up.  Just the usual stabilization phase.

I'm afraid I tend to point out the obvious to everybody on a regular
basis.  When talking over e-mail, I think it's important to make sure
that everybody is in basic agreement, and I try to accomplish that by
continually reiterating the basis for communication.  I mean no
offense, although unfortunately some people do get offended.  In
general, though, I would rather offend somebody by telling them
something that any idiot knows than I would let a bug get into the
code because somebody in fact doesn't know it, or forgot it.

I find a case like omitting mips16 support pretty scary, because there
isn't much testing for this sort of thing, so it is likely to get
caught months later by somebody who has no idea what has happened to
the code.  I assumed that you broke apart the functions without
changing the functionality; had I noticed that you were actually
changing what they did, I would not have approved the patch.

Ian

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