Re: load of in-place relocation addend in AArch64

["Frédéric Rivière" <frederic.riviere@microej.com>]

Hi Nick,

I understand the reason and I agree with a warning, because in the 
meantime I realized that REL relocations are correctly supported when 
there is no in-place addend.

So we could improve the message as following:

"Warning: REL type relocations are not expected for architecture 
'aarch64' - in-place addends with non-zero values are not supported."

Also I believe it would be perfect if this message could be printed only 
during the relocation process, to avoid impacting the other tools.

I'm not familiar with LD code base but is there any chance to be able to 
retrieve the original relocation kind when we are in the 
"elfNN_aarch64_relocate_section" function ?

(for example by being able to retrieve the original relocation section 
type or the relocation entry size for example)

Best Regards,

--Frédéric

On 12/7/2023 6:16 PM, Nick Clifton wrote:
> Hi Frédéric,
>
>   OK, I have produced a small patch (attached) which adds this warning
>   message to the linker's output:
>
>     $ ld test_AArch64_with_REL.o
>     ld: test_AArch64_with_REL.o: Warning: REL type relocations are not 
> expected for architecture 'aarch64' - support may be incomplete
>
>   This warning does not actually stop the link from completing however.
>   The reason for this is that the code where the relocations are loaded
>   is shared by other tools, which do still work with REL relocations.
>   For example the objdump tool is able to display the relocations without
>   any problems:
>
>     $ objdump -r test_AArch64_with_REL.o
>     BFD: test_AArch64_with_REL.o: Warning: REL type relocations are 
> not expected for architecture 'aarch64' - support may be incomplete
>
>     test_AArch64_with_REL.o:     file format elf64-littleaarch64
>
>     RELOCATION RECORDS FOR 
> [.text.__icetea__virtual__com_is2t_icetea_support_test_BImpl___bar__I]:
>     OFFSET           TYPE              VALUE
>     0000000000000008 R_AARCH64_ABS32 
> com_is2t_icetea_support_test_AImpl___bar
>     [...]
>
>   This strikes me as a compromise solution at best, but it is better
>   than the current situation nonetheless.
>
>   What do you think ?
>
> Cheers
>   Nick
>
>
>
-- 
MicroEJ <http://www.microej.com> 	

Frédéric RIVIERE
/CTO Office Member & VP Product/

11 rue du Chemin Rouge - Bat. D 44373 Nantes Cedex 3, France 
https://www.linkedin.com/in/fredericriviere/

Twitter <https://twitter.com/microej> LinkedIn 
<https://www.linkedin.com/company/microej> Youtube 
<https://www.youtube.com/@MicroEJ_News>

event <https://www.microej.com/event/>

This email (and all attachments) may contain information that is 
proprietary privileged, and/or confidential. If you received this e-mail 
in error or if it was improperly forwarded to you, the information 
contained in the e-mail should, at all times, remain confidential. 
Please notify the sender immediately by e-mail, and delete or destroy 
the original and any copies. Any unauthorized use, disclosure, 
reproduction, retention or distribution by any person other than the 
intended recipient is strictly prohibited.