14603 2012-09-21 08:43:00 +0000 no reloc emitted for ld generated veneers for ARM 2012-09-21 11:09:02 +0000 1 1 1 Unclassified binutils ld unspecified All All REOPENED P2 normal --- 1 marcin.bukat unassigned mgretton 57520 6642 marcin.bukat 2012-09-21 08:43:49 +0000 Created attachment 6642 testcase The simple test case provided shows that 0x80000000 constant used as jump address in veneer generated by ld has no reloc associated. I believe this is a bug (or inconsistency at least). I noticed this working on bFLT loader for the target with memory split - fast internal ram and regular dram. With current ld behavior runtime relocation is broken by this. The workaround is to use -mlong-calls when compiling C sources but this imposes performance penalty as well as does not solve the problem of asm files. Tested with 2.20.1 as well as with current snapshot. 57522 mgretton 2012-09-21 09:13:48 +0000 The testcase doesn't mark the branch destination as a function. The linker will only veneer function calls. The test should work fine with the following source: .text .arm .global _start _start: bl far_foo .section .far_text,"ax" .arm .global far_foo .type far_foo, %function @ For thumb you would instead do: .thumb_func far_foo: nop bx lr For further examples see ld/testsuite/ld-arm/farcall-*.s source files. 57523 marcin.bukat 2012-09-21 09:19:32 +0000 Running provided testcase I get this: test.elf: file format elf32-littlearm Disassembly of section .text: 00000000 <_start>: 0: eb000000 bl 8 <__far_foo_veneer> 0: R_ARM_CALL far_foo 4: 00000000 andeq r0, r0, r0 00000008 <__far_foo_veneer>: 8: e51ff004 ldr pc, [pc, #-4] ; c <__far_foo_veneer+0x4> c: 80000000 .word 0x80000000 Disassembly of section .far_text: 80000000 <far_foo>: 80000000: e1a00000 nop ; (mov r0, r0) 80000004: e12fff1e bx lr 80000004: R_ARM_V4BX *ABS* There is clearly veneer inserted as well as with your proposed change. But this is not the case. The bug is about lack of relocation in veneer jump address which still holds. 57524 mgretton 2012-09-21 09:43:34 +0000 Surely as you have linked the image together and it is now fully relocated, the linker doesn't need to create relocations for veneers? The test case you provide only contains static relocations. These are applied once at static link time, and cannot - in general - be reapplied after linking (as if the relocations have been specified with .rel sections the necessary addend has been destroyed). If you want to do runtime linking and relocation you need to use dynamic relocations which do not get fixed by the static linker. 57525 marcin.bukat 2012-09-21 11:09:02 +0000 elf2flt allows you to take fully resolved elf binary produced with --emit-relocs and produce flat file which is relocated at load time. I want to archive the same but with address space split. I do understand why usually it is not needed but veneer inserted by ld can be seen like any other code coming from object files. It does introduce new symbols, but does not create relocation for this symbols. I see this as inconsistency at least. 6642 2012-09-21 08:43:00 +0000 2012-09-21 08:43:49 +0000 testcase arm-eabi-test.tar.bz2 application/x-bzip 598 marcin.bukat QlpoOTFBWSZTWYS/tvwAAbh/xMywQEBUd//Tf//eIf+//toQAAAAwAhAAjzswjawSiJGI2pqbEmj 1A0ABo9INANBpp6gaNHqHDTTBDIaaZGTCAaaAMJo0yYAEDQSJUTyRk3qT0gPUAAAAAMgABoAJQQQ hqntUwn6TKDCYNQHqYhjQm1G0mmmGjy7gy9hqaqYZSBboqAi0IgCYMMiwoAdHxNid2a/EKAJogog DMChSn7zt+o+FkYbOd49m6c1XhR/q6lTQIY72fglatNLzirOyTJ69tFCAvNJg0gvkJA+PMGS322x zossSPgrS0eWLrFZh8Zzzg5Cc1HIp0ZlHks5GDz980lVDlDAD8jcJNGsriWgHrJeoa36XWSwiO4q oobBekYeCURjZIklIaJygE0xgXkQtUEPyZunN1QuAkgLWVUYDgB7gPAFDIuW1gJuHCrOHDSQL8Wm sVkwUQojVApKVAZIsTR6kqHOsYgtMpsBInYmPS+l42vWrIJtHqL+tgjnLc0wwmzS0h2ykxmAoMkR SN0fUUpLMqrKMk9jHGNLi78D0BM8o6KSFGxtkYy0rCSOstMxDRcJ0yDuNCSbOalsK6JJ8lZuuF4Q 9yGqr4ntJAlz03DKiLbI48T6mauAz+HkRnh+2yqncRZAJjHYalNBK1F+rW0oClKmxGHYcOUxy+NQ kdBdUewVVRQHK6zU1aIXBy6M1Y/kBXYmSbFmnwAhiGzgaR6VyIjCEWQkuKhpsyRENKXQFnVwWIFF LsY6oLoVBPJ4BKI+A4IyAED/F3JFOFCQhL+2/A==