Support for R_ARM_THM_MOVW_ABS_NC / R_ARM_THM_MOVT_ABS relocations?

[tpetazzoni]

When building some Buildroot packages for ARM Cortex-M (ARMv7-M), we sometimes see movt/movw instructions generated with corresponding R_ARM_THM_MOVW_ABS_NC and/or R_ARM_THM_MOVT_ABS relocations generated:

00000380  00003f2f R_ARM_THM_MOVW_AB 00000000   PawnHashKey
00000388  00003f30 R_ARM_THM_MOVT_AB 00000000   PawnHashKey
00000464  00003f2f R_ARM_THM_MOVW_AB 00000000   PawnHashKey
00000470  00003f30 R_ARM_THM_MOVT_AB 00000000   PawnHashKey

Unfortunately, these types of relocations are not handled by elf2flt, which errors out with:

ERROR: reloc type R_ARM_THM_MOVW_ABS_NC unsupported in this context
ERROR: reloc type R_ARM_THM_MOVT_ABS unsupported in this context
ERROR: reloc type R_ARM_THM_MOVW_ABS_NC unsupported in this context
ERROR: reloc type R_ARM_THM_MOVT_ABS unsupported in this context

Would it be possible to add support for these relocation types ?

[RomainNaour]

Hi @gregungerer @cpriouzeau,

This is another issue with ARM Cortex-m4 toolchain and elf2flt tool, there are more details/context in this message [1] in the Buildroot mailing-list.

Can you have a look?

[1] http://lists.busybox.net/pipermail/buildroot/2019-June/253203.html

Best regards, Romain

[gregungerer]

Hi Romain, Thomas,

On 7/11/19 10:52 pm, Romain Naour wrote:

Hi @gregungerer https://github.com/gregungerer @cpriouzeau https://github.com/cpriouzeau,

This is another issue with ARM Cortex-m4 toolchain and elf2flt tool, there are more details/context in this message [1] in the Buildroot mailing-list.

Can you have a look?

I have been thinking about this one over the last few weeks.

From what I currently see there is really no easy way to implement those R_ARM_THM_MOVW_ABS_NC and R_ARM_THM_MOVT_ABS relocation types. I am not saying it is impossible, but it looks like it would need support in the relocation code of the kernels flat loader to deal with the bit/address mangling required at load/relocate time.

[1] http://lists.busybox.net/pipermail/buildroot/2019-June/253203.html

I would say using -fpic is a reasonable solution here. Most likely it results in use of a GOT and that would not need absolute relocations.

I have not used thumb targeted platforms, so I am not really familiar with what the resulting generated code and relocations looks like though.

Regards Greg

Best regards, Romain

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/uclinux-dev/elf2flt/issues/11?email_source=notifications&email_token=AAIOZ2HK3L62NFR4THQNPV3QSQFQTA5CNFSM4H2ZPQY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDMJXUY#issuecomment-551066579, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIOZ2CVGCNS4QDUKOILTVTQSQFQTANCNFSM4H2ZPQYQ.

[tpetazzoni]

So, in the end, what should be do about this? Compiling with -fpic seems like a weird workaround for statically-linked binaries. We continue to have build failures caused by this in Buildroot.

[plauche]

@tpetazzoni did you ever have any insight into how to work around this?

I am running into a similar issue. The PIC suggestion is interesting, as that is how I ended up here in the first place. I inferred from this mailing list post that having PIC enabled was the root of my issue (reloc outside program on a cortex-m3 target), but disabling it led me to these other unsupported relocations.