Lines Matching full:addend
105 . {* addend for relocation value. *}
106 . bfd_vma addend;
145 o <<addend>>
147 The <<addend>> is a value provided by the back end to be added (!)
187 0x12340000 in their addend field. The data would consist of:
199 it to the addend to get the original offset, and then adds the
328 . {* Some formats record a relocation addend in the section contents
332 . addend is recorded with the section contents; when performing a
335 . recorded with the relocation (in arelent.addend); when performing
347 . addend in the reloc, eg. ELF USE_REL, src_mask will normally equal
348 . dst_mask to extract the addend from the section contents. If
349 . relocations do have an addend in the reloc, eg. ELF USE_RELA, this
561 basic coff) have no way of specifying an addend in the
562 relocation type, so the addend has to go in the output data.
564 slot will always be big enough for the addend. Complex reloc
640 /* Add in supplied addend. */
641 relocation += reloc_entry->addend;
644 symbol we are relocating against, plus any addend. */
657 the addend to be the negative of the position of the location
667 which means we must adjust the existing addend by the change
669 we do not want to adjust the existing addend at all.
690 reloc_entry->addend = relocation;
709 /* For m68k-coff, the addend was being subtracted twice during
725 is that the current code ignores the reloc addend when producing
734 BFD handles this by setting the addend to the negative of the old
745 reloc_entry->addend to 0 for all cases, since it is, in fact, going to
747 which doesn't use the addend; I'm not sure what it will do to other
749 the addend and set partial_inplace).
755 specifically adds the addend field into the object file, knowing that
757 coff-i386.c will wind up adding the addend field in twice. It's
778 relocation -= reloc_entry->addend;
779 reloc_entry->addend = 0;
783 reloc_entry->addend = relocation;
1022 /* Add in supplied addend. */
1023 relocation += reloc_entry->addend;
1026 symbol we are relocating against, plus any addend. */
1039 the addend to be the negative of the position of the location
1049 which means we must adjust the existing addend by the change
1051 we do not want to adjust the existing addend at all.
1070 reloc_entry->addend = relocation;
1089 /* For m68k-coff, the addend was being subtracted twice during
1105 is that the current code ignores the reloc addend when producing
1114 BFD handles this by setting the addend to the negative of the old
1125 reloc_entry->addend to 0 for all cases, since it is, in fact, going to
1127 which doesn't use the addend; I'm not sure what it will do to other
1129 the addend and set partial_inplace).
1135 specifically adds the addend field into the object file, knowing that
1137 coff-i386.c will wind up adding the addend field in twice. It's
1157 relocation -= reloc_entry->addend;
1160 reloc_entry->addend = 0;
1164 reloc_entry->addend = relocation;
1323 ADDEND is the addend of the reloc. */
1332 bfd_vma addend)
1343 ADDEND, any addend associated with the reloc. */
1344 relocation = value + addend;
1542 value and discarding any in-place addend. This is used for fixed-up
2049 "addend" in some special way.
2052 addend is the displacement in bytes of the "lda" instruction from
2058 with GPDISP_HI16 relocs. The addend is ignored when writing the
2081 section symbol. The addend is ignored when writing, but is filled
2094 as the absolute section symbol), and the "addend" indicates the type
2569 The addend of this reloc is an alignment power that must
5287 is stored in the reloc's addend. For Rel hosts, we are forced to put
6437 Same as BFD_RELOC_32_PCREL but with an implicit -1 addend.
6441 Same as BFD_RELOC_32_PCREL but with an implicit -2 addend.
6445 Same as BFD_RELOC_32_PCREL but with an implicit -4 addend.
7601 (*parent)->addend = 0;
7644 (*parent)->howto->name, (*parent)->addend,
