MIPS md_apply_fix()(?) problem.
Richard Sandiford
rsandifo@redhat.com
Fri Nov 9 08:36:00 GMT 2001
More information about the Binutils mailing list
Fri Nov 9 08:36:00 GMT 2001
- Previous message (by thread): MIPS md_apply_fix()(?) problem.
- Next message (by thread): MIPS md_apply_fix()(?) problem.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): MIPS md_apply_fix()(?) problem.
- Next message (by thread): MIPS md_apply_fix()(?) problem.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list