XCOFF64 gas patch

Ian Lance Taylor ian@zembu.com
Mon Apr 10 12:16:00 GMT 2000


   Date: Mon, 10 Apr 2000 13:27:56 -0500
   From: Clinton Popetz <cpopetz@cygnus.com>

   This is related to the FIXME at the top of that block of code:

	    FIXME: We need to handle the DS field at the very least.

   because for ppc64 we emit a lot of TOC loads like:

	   ld 9,LC..0(2)

   which uses:

   { "ld",      DSO(58,0), DS_MASK,        PPC64,          { RT, DS, RA } },

   Where DS is:

     { 16, 0, insert_ds, extract_ds, PPC_OPERAND_PARENS | PPC_OPERAND_SIGNED },

   So operand->insert is in this case insert_ds, not NULL.  Perhaps someone can
   explain why the operand->insert check is there, and I can try to fix it from
   there?  

The general idea, as you probably know, is to pick out the relocations
which we can represent in the object file.  However, we need to make
certain that we do not accidentally think we can handle a relocation
which we can not actually handle.

The operand->insert check is there specifically to distinguish the D
field from the DS field.  I think I was thinking that the D field and
the DS field could not be handled by the same relocation type, because
there are values which can be used for the D field which can not be
used for the DS field.  Therefore, any relocation which handles the DS
field requires additional error checking--the address has to be
properly aligned.

However, given that we are talking about the TOC section, it does seem
reasonable to require the BFD_RELOC_PPC_TOC16 relocation to do that
extra error checking.  In that case, we can simply omit the
operand->insert check.

Does that make sense?

Ian


More information about the Binutils mailing list