binutils/bfd/reloc.c

106 .  {* addend for relocation value.  *}
107 .  bfd_vma addend;
146 	o <<addend>>
148 	The <<addend>> is a value provided by the back end to be added (!)
188         0x12340000 in their addend field. The data would consist of:
200         it to the addend to get the original offset, and then adds the
308 .      data section of the addend.  The relocation function will
332 .  {* Some formats record a relocation addend in the section contents
336 .     addend is recorded with the section contents; when performing a
339 .     recorded with the relocation (in arelent.addend); when performing
351 .     addend in the reloc, eg. ELF USE_REL, src_mask will normally equal
352 .     dst_mask to extract the addend from the section contents.  If
353 .     relocations do have an addend in the reloc, eg. ELF USE_RELA, this
565 	basic coff) have no way of specifying an addend in the
566 	relocation type, so the addend has to go in the output data.
568 	slot will always be big enough for the addend. Complex reloc
644   /* Add in supplied addend.  */
645   relocation += reloc_entry->addend;
648      symbol we are relocating against, plus any addend.  */
661 	 the addend to be the negative of the position of the location
671 	 which means we must adjust the existing addend by the change
673 	 we do not want to adjust the existing addend at all.
694 	  reloc_entry->addend = relocation;
713 	      /* For m68k-coff, the addend was being subtracted twice during
729 is that the current code ignores the reloc addend when producing
738 BFD handles this by setting the addend to the negative of the old
749 reloc_entry->addend to 0 for all cases, since it is, in fact, going to
751 which doesn't use the addend; I'm not sure what it will do to other
753 the addend and set partial_inplace).
759 specifically adds the addend field into the object file, knowing that
761 coff-i386.c will wind up adding the addend field in twice.  It's
782 	      relocation -= reloc_entry->addend;
783 	      reloc_entry->addend = 0;
787 	      reloc_entry->addend = relocation;
793       reloc_entry->addend = 0;
1030   /* Add in supplied addend.  */
1031   relocation += reloc_entry->addend;
1034      symbol we are relocating against, plus any addend.  */
1047 	 the addend to be the negative of the position of the location
1057 	 which means we must adjust the existing addend by the change
1059 	 we do not want to adjust the existing addend at all.
1078       reloc_entry->addend = relocation;
1097 	  /* For m68k-coff, the addend was being subtracted twice during
1113 is that the current code ignores the reloc addend when producing
1122 BFD handles this by setting the addend to the negative of the old
1133 reloc_entry->addend to 0 for all cases, since it is, in fact, going to
1135 which doesn't use the addend; I'm not sure what it will do to other
1137 the addend and set partial_inplace).
1143 specifically adds the addend field into the object file, knowing that
1145 coff-i386.c will wind up adding the addend field in twice.  It's
1165 	  relocation -= reloc_entry->addend;
1168 	    reloc_entry->addend = 0;
1172 	  reloc_entry->addend = relocation;
1331    ADDEND is the addend of the reloc.  */
1340 			  bfd_vma addend)
1351      ADDEND, any addend associated with the reloc.  */
1352   relocation = value + addend;
1548    of zero and discarding any in-place addend.  This is used for fixed-up
1986      "addend" in some special way.
1989      addend is the displacement in bytes of the "lda" instruction from
1995      with GPDISP_HI16 relocs.  The addend is ignored when writing the
2018      section symbol.  The addend is ignored when writing, but is filled
2031      as the absolute section symbol), and the "addend" indicates the type
4218   is stored in the reloc's addend.  For Rel hosts, we are forced to put
5239 	      (*parent)->addend = 0;
5282 			 (*parent)->howto->name, (*parent)->addend,