https://sourceware.org/bugzilla/show_bug.cgi?id=16202
--- Comment #4 from ma.jiang at zte dot com.cn --- (In reply to Nick Clifton from comment #1) > Created attachment 7337 [details] Proposed patch =============================================== This patch can solve the abs8 problem.In fact,I have considered a simliar fix. The reason that I choose to fix the ABS8 branch not the top one, is That I found many branches(eg, R_ARM_THM_ABS5) had already refetched the addend. I think it's more safe to follow their way--fix the problem and make sure not to throw new problems.Changing the top addend may touch many other branches, I could not make sure all of them were ok with the change. Today, after reading all branches of elf32_arm_final_link_relocate again, I think it is ok to change the top addend. But still there are something need to discuss. First, some relocs require to read more bytes than its bitsize shows.For example,R_ARM_ABS12 is set to the first byte of the instruction, and its bitsize is 12. So, using bfd_get_16 to get addend is not right. R_ARM_ABS12 is ok, as it seems only used by vxworks,and does not get addend from instructions(globals->use_rel=0). For other similar relocs such as R_ARM_ALU_PCREL7_0,R_ARM_MOVW_ABS_NC and R_ARM_MOVT_ABS, addend is refeteched in their branches. So, This is just a hidden danger for now.But we should pay attention. Second, some relocs (eg,R_ARM_THM_JUMP6) refecthed the addend. They will not need the refetch process any more if the proposed patch applied. It will be better if the patch do some clean for this, I think. At last ,I think the Root Cause of this problem is the reloc_howto mechanism. This mechanism failed to provide a clear abstraction for relocations, as it exposed too many details. As a result, almost every reloc process branch has to do some special things.In fact, the only thing that caller should know and set is the relocation type. The reloc_howto mechanism should automaticlly finished remaining dirty work such as adjusting the mask for big endian target, extracting the addend, computing the reloc result, and Writing back results. Adding some new callbacks for reloc_howto_struct can do the job, this is not very hard theoretically, but the real amount of work could be horrible. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
