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

[Cary Coutant <ccoutant at gmail dot com>]

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

Thanks!

>> 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?  :)

I'll consider that. That got kind of ugly in the MIPS backend, anyway.

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

Yes, we're really counting on the compiler's optimization here.

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

I don't think you need to copy the whole relocation -- all you need to
save is the r_offset and r_addend of the last REL16_HA relocation, and
saving that as state in the Target class (only one copy) means you
don't have to instantiate a new accessor and (maybe) byte-swap and
bit-extract fields from the previous reloc all over again.

Besides, if you're interested in the next relocation, you still don't
have enough to know whether there *is* a next reloc. Besides relnum,
you'll also need nrelocs. I'd prefer not to add that, too.

-cary