Re: [GOLD] Add more params to relocate() and relocate_section()

[Alan Modra <amodra at gmail dot com>]

On Mon, Dec 07, 2015 at 06:17:55PM -0800, Cary Coutant wrote:
> > Some linker code editing needs to change multiple insns.  In some
> > cases multiple relocations are involved and it is not sufficient to
> > make the changes independently as relocations are processed, because
> > doing so might lead to a partial edit.  So in order to safely edit we
> > need all the relocations available in relocate().  Also, to emit
> > edited relocs corresponding to the edited code sequence we need some
> > way to pass information from relocate() to relocate_relocs(),
> > particularly if the edit depends on insns.  We can't modify input
> > relocs in relocate() as they are mmapped PROT_READ, nor it is
> > particularly clean to write relocs to the output at that stage.  So
> > add a Relocatable_relocs* parameter to mark edited relocs.
> 
> I'm OK with adding the Relocatable_relocs* parameter, though I think
> it would be simpler to add it to struct Relocate_info. Since it's
> already a parameter to scan_relocatable_relocs() and
> relocate_relocs(), I guess there's precedent. Would you consider
> adding it to struct Relocate_info, and then later removing the
> redundant parameter from relocate_relocs()? (It would still need to be
> passed to scan_relocatable_relocs(), since there's no Relocate_info
> parameter there.)

OK, I'm happy to look at doing that.

> I'm not wild about adding the preloc parameter -- it's kind of
> redundant with the rel/rela parameter,

I agree.  How about removing the rel/rela parameter?  :)

> and it just seems like an
> unmanaged way to access the previous relocation.

Ah, but I'm a wild-west C programmer!  Seriously, accessor classes
like elfcpp::Rela are nice but I'm dubious about passing them around
as function parameters.  I know the functions are inline, but if they
aren't actually inlined won't that mean elfcpp::Rela:p_ needs to exist
in memory?

> I looked at how
> you're planning to use it in the ELFv2 patch, and it seems like it
> would be better to manage state in the Target class to track whether
> the previous relocation was a R_POWERPC_REL16_HA with all the right
> qualifications. This is not without precedent -- see
> skip_call_tls_get_addr_ in the i386, x86_64, and aarch64 targets for
> an example.

What if I'd like to access the next relocation?  Sometimes that's the
natural way to write relocation processing code.  OK, I guess you can
always save state about the first reloc for later processing when you
have the next relocation, but I'm not keen on state.  Saving state
here would typically mean copying a reloc, and who needs more memory
copying?

-- 
Alan Modra
Australia Development Lab, IBM