This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: MIPS md_apply_fix()(?) problem.
Nick Clifton <nickc@cambridge.redhat.com> writes:
> I was actually thinking of doing that. (Maybe you would like to have
> a go too ?)
I can try! I'll need to be told what to do, though.
> My plan was to tidy up write.c:fixup_segment() to remove
> all the target specific code, and get rid of the target specific bit
> fields in the fixup structure. (Move them into tc_fix_data).
>
> Then I was going to add a new bitfield to the fixup which would
> fixup_segment would set if it had added in the symbol's value before
> calling md_apply_fix3. Backends could then examine this flag and undo
> the addition if they wanted to. In fact it might be better to have a
> target specific macro that fixup_segment uses to check to see whether
> it should add in the symbol's value in the first place.
Would this stuff affect bfd_install_relocation too?
Having that macro would definitely get rid of some of the MIPS
clumsiness, but the real headache is having to hack around the weird
things that bfd_install_relocation does to the reloc. It'd be great if
tc-mips's md_apply_fix3 didn't have to subtract the value twice when it
thinks bfd_install_relocation is going to add it back in again.
Would it possible to move all the addend twiddling out of
bfd_install_relocation and rely only on this new fixup handling
instead?
Richard