This is the mail archive of the binutils@sourceware.org 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]
Other format: [Raw text]

Re: [PATCH][gold] Mips: Add support for resolving multiple consecutive relocations


>         * aarch64.cc (Target_aarch64::Relocate::relocate): Add reloc_count
>         parameter.
>         * i386.cc (Target_i386::Relocate::relocate): Likewise.
>         * powerpc.cc (Target_powerpc::Relocate::relocate): Likewise.
>         * s390.cc (Target_s390::Relocate::relocate): Likewise.
>         * sparc.cc (Target_sparc::Relocate::relocate): Likewise.
>         * tilegx.cc (Target_tilegx::Relocate::relocate): Likewise.
>         * x86_64.cc (Target_x86_64::Relocate::relocate): Likewise.
>         * arm.cc (Target_arm::::Relocate::relocate): Likewise.
>         (Target_arm::relocate_stub): Pass -1U for reloc_count to relocate.
>         * mips.cc (Target_mips::Relocate::calculated_value_): New data
>         member.
>         (Target_mips::Relocate::calculate_only_): Likewise.
>         (Target_mips::Relocate::relocate): Handle multiple consecutive
>         relocations with the same offset.
>         * target-reloc.h (relocate_section): Pass reloc_count to relocate.
>         (apply_relocation): Pass -1U for reloc_count to relocate.

Rather than make all these changes to add a parameter to
Relocate::relocate, the reloc_count can be recomputed from what's in
relinfo:

      size_t reloc_count = (relinfo->shdr.get_sh_size()
                            / relinfo->shdr.get_sh_entsize());

I might actually consider adding reloc_count directly to Relinfo, and
removing it from the interfaces where it's already being passed, but
that's a cleanup for a later date.

-cary


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