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


On Thu, Jun 22, 2017 at 07:52:07AM -0700, Cary Coutant wrote:
> > 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

OK, I'll do that, and assume you're OK with the rest of the series.

> 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.

BTW, why the reluctance to add another parameter to an inline?  Won't
a decent compiler generate equivalent code to that prior to adding the
param for any targets that don't use the param?  I know, I shouldn't
care too much about how compilers work.  I'm really just curious.
(And if reduction in parameter count is a goal, then at first glance
sh_type, target, and output_section could be put in relinfo too.)

-- 
Alan Modra
Australia Development Lab, IBM


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