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 more params to relocate() and relocate_section()


Sorry, Alan, your patches got stacked up behind the MIPS-64 patch
series, for which I'm working on a minor restructuring of the target
interfaces (to better isolate the target-independent code from the
on-disk relocation format).

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

I'm not wild about adding the preloc parameter -- it's kind of
redundant with the rel/rela parameter, and it just seems like an
unmanaged way to access the previous relocation. 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.

-cary


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