[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/16202] ABS8 and ABS16 get wrong addend on ARM-ELF (big endian)

From: ma.jiang at zte dot com.cn
Subject: [Bug ld/16202] ABS8 and ABS16 get wrong addend on ARM-ELF (big endian)
Date: Mon, 06 Jan 2014 06:53:59 +0000


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]