This is the mail archive of the binutils@sources.redhat.com 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: 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


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