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: [GOLD] Add reloc_count param to Relocate::relocate


> This is to support peeking at the next reloc.  OK?
>
> Following patches will make use of this on PowerPC64, to check whether
> an R_PPC64_TOCSAVE reloc follows a relocation on a call.
>
>         * target-reloc.h (relocate_section): Pass reloc_count to relocate().
>         (apply_relocation): Similarly, but pass 0.
>         * aarch64.cc (Target_aarch64::Relocate::relocate): Add ignored
>         reloc_count param.
>         * arm.cc (Target_arm::Relocate::relocate): Likewise.
>         * i386.cc (Target_i386::Relocate::relocate): Likewise.
>         * mips.cc (Target_mips::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.

The mips backend already needed the reloc_count in Relocate::relocate,
but it can be easily computed from relinfo. See my earlier email to
Vladimir on this same topic:

https://sourceware.org/ml/binutils/2017-03/msg00233.html

I said there: "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." With two
backends now needing it, perhaps this cleanup is due now. If you want
to change your subsequent patches to compute reloc_count as I
suggested, I'll work on that cleanup patch.

-cary


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