• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 1020 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

MSP430 relocation types

CCS/MSP430-GCC-OPENSOURCE: Link error on R_MSP430X_10_PCREL

Lorenzo Marcantonio76
Prodigy 160 points

Part Number: MSP430-GCC-OPENSOURCE
Other Parts Discussed in Thread: MSP430F5172

Tool/software: Code Composer Studio

I'm using this compiler/linker, downloaded yesterday just to be sure (it occured even with the gcc 5 version): msp430-elf-gcc (Mitto Systems Limited - msp430-gcc 8.3.1.25) 8.3.1 GNU ld (Mitto Systems Limited - msp430-gcc 8.3.1.25) 2.26.20160125 Occasionally build fails with /tmp/ccwPDzmE.ltrans0.ltrans.o: In function `.L325': :(.text+0x1a86): relocation truncated to fit: R_MSP430X_10_PCREL against `.L326' In my experience relocation errors occurs when either 1) the program doesn't fit in memory or 2) for some reason a relative jump is too long and can't be done 1) certainly isn't true since the final program is less than 10kB of code; 2) would indicate a code generator/optimizer bug. In fact it only happens with certain compiler optimization flags; with -mmcu=msp430f5172 -O2 -Wall -Wextra --lto sometimes fails, but with -mmcu=msp430f5172 -Os -Wall -Wextra --lto it compiles fine (it even makes smaller code, as implied by Os) I suspect a compiler bug, any idea on that? For the moment I'll work with -Os but having to cope with a flaky compiler is not reassuring
  • 0
    Expert 2410 points

    Hi,

    Does the relocation overflow get fixed if you disable linker relaxation using the option "-Wl,--no-relax"?

    Please rebuild the program with "--save-temps" and a "-o" option specified for the linker output, this will save the "ltrans.o" output file which we need to take a look at.

    Please then provide the "msp430-elf-objdump -d" output of the instruction at 0x1a86 offset from the .text section in the ltrans.o file specified in the error message.

    Can you also provide the addresses of .L325 and .L326 from this .ltrans.o file.

    Thanks,

  • 0 in reply to Jozef_Lawrynowicz
    Prodigy 160 points
    adding -Wl,--no-relax gives even more relocation faults, in fact it stops with "additional relocation overflows omitted from the output". objdumping the output of --save-temps isn't useful since it only seems to give the lto stuff, before code generation (i.e. there is no .text section in the bledacan.elf.ltrans0.o file but lots of .gnu.lto_.* stuff). I can supply the whole *.o fileset if needed
  • 0 in reply to Lorenzo Marcantonio76
    Prodigy 160 points
    Made some progress. For some reason the error changed to bledacan.elf.ltrans0.ltrans.o: In function `.L309': :(.text+0x1a7e): relocation truncated to fit: R_MSP430X_10_PCREL against `.L310' the --keep-temps also left a ltrans0.s file, I gave it to as and from the listing this appeared: 2477 1a4e 3040 0000 BR #.L310 2478 .L309: 2479 1a52 7D90 C4FF CMP.B #-60, R13 { JEQ .L312 2479 0024 2480 1a58 7D90 C6FF CMP.B #-58, R13 { JNE .L306 2480 0020 2481 1a5e 1C42 0000 MOV.W &ble_pstate, R12 2482 1a62 2C93 0024 CMP.W #2, R12 { JEQ .L310 2483 1a66 3C90 0300 CMP.W #3, R12 { JNE .L344 2483 0020 2484 1a6c 3A92 0020 CMP.W #8, R10 { JNE .L345 2485 1a70 5C42 0000 MOV.B &ble_rx_buf+10, R12 2486 1a74 7640 1200 MOV.B #18, R6 2487 1a78 469C 002C CMP.B R12, R6 { JHS .L345 2488 1a7c 5C42 0000 MOV.B &ble_rx_buf+3, R12 2489 1a80 0C93 0020 CMP.W #0, R12 { JNE .L345 2490 1a84 3A40 0000 MOV.W #ble_peer_mac, R10 However from my interpretation 0x1a7e refers to ble_rx_buf+3 (a data address) in the MOV.B at 0x1a7c, right? I don't see how that would fit with .L310 (a code address), which is here: 2203 1682 4E9F 0024 CMP.B R15, R14 { JEQ .L299 2204 .L310: 2205 1686 B240 FF7F MOV.W #32767, &ble_rx_ptr 2205 0000 2206 168c 8243 0000 MOV.W #0, &ble_rx_len Maybe it's generating the wrong type of relocation? Please tell if you need any other data OK, got some more info. The clue wasn't in the *.o file but in the .s file… For some reason the message changed, however, given the message: bledacan.elf.ltrans0.ltrans.o: In function `.L309': :(.text+0x1a7e): relocation truncated to fit: R_MSP430X_10_PCREL against `.L310' I assembled the temporary and the listing gave me this: 2478 .L309: 2479 1a52 7D90 C4FF CMP.B #-60, R13 { JEQ .L312 2479 0024 2480 1a58 7D90 C6FF CMP.B #-58, R13 { JNE .L306 2480 0020 2481 1a5e 1C42 0000 MOV.W &ble_pstate, R12 2482 1a62 2C93 0024 CMP.W #2, R12 { JEQ .L310 2483 1a66 3C90 0300 CMP.W #3, R12 { JNE .L344 2483 0020 2484 1a6c 3A92 0020 CMP.W #8, R10 { JNE .L345 2485 1a70 5C42 0000 MOV.B &ble_rx_buf+10, R12 2486 1a74 7640 1200 MOV.B #18, R6 2487 1a78 469C 002C CMP.B R12, R6 { JHS .L345 2488 1a7c 5C42 0000 MOV.B &ble_rx_buf+3, R12 2489 1a80 0C93 0020 CMP.W #0, R12 { JNE .L345 2490 1a84 3A40 0000 MOV.W #ble_peer_mac, R10
  • 0 in reply to Lorenzo Marcantonio76
    Prodigy 160 points
    SORRY but the forum form got mad at me. Reposting: Made some progress. For some reason the error changed to bledacan.elf.ltrans0.ltrans.o: In function `.L309': :(.text+0x1a7e): relocation truncated to fit: R_MSP430X_10_PCREL against `.L310' the --keep-temps also left a ltrans0.s file, I gave it to as and from the listing this appeared: 2477 1a4e 3040 0000 BR #.L310 2478 .L309: 2479 1a52 7D90 C4FF CMP.B #-60, R13 { JEQ .L312 2479 0024 2480 1a58 7D90 C6FF CMP.B #-58, R13 { JNE .L306 2480 0020 2481 1a5e 1C42 0000 MOV.W &ble_pstate, R12 2482 1a62 2C93 0024 CMP.W #2, R12 { JEQ .L310 2483 1a66 3C90 0300 CMP.W #3, R12 { JNE .L344 2483 0020 2484 1a6c 3A92 0020 CMP.W #8, R10 { JNE .L345 2485 1a70 5C42 0000 MOV.B &ble_rx_buf+10, R12 2486 1a74 7640 1200 MOV.B #18, R6 2487 1a78 469C 002C CMP.B R12, R6 { JHS .L345 2488 1a7c 5C42 0000 MOV.B &ble_rx_buf+3, R12 2489 1a80 0C93 0020 CMP.W #0, R12 { JNE .L345 2490 1a84 3A40 0000 MOV.W #ble_peer_mac, R10 However from my interpretation 0x1a7e refers to ble_rx_buf+3 (a data address) in the MOV.B at 0x1a7c, right? I don't see how that would fit with .L310 (a code address), which is here: 2203 1682 4E9F 0024 CMP.B R15, R14 { JEQ .L299 2204 .L310: 2205 1686 B240 FF7F MOV.W #32767, &ble_rx_ptr 2205 0000 2206 168c 8243 0000 MOV.W #0, &ble_rx_len Maybe it's generating the wrong type of relocation? Please tell if you need any other data
  • 0 in reply to Lorenzo Marcantonio76
    Expert 2410 points

    "*.ltrans0.ltrans.o" should be a regular object file containing the .text section, but yes "*.ltrans0.o" contains only the LTO stuff.

    But yes please zip up all of the temporary files and I'll take a look.

    I've fixed a similar relocation overflow recently, and it will be in the next release of MSP430-GCC. It is also available in upstream binutils. If you'd like, I can provide instructions for how to build this version of binutils. If you have a linux machine, this is quite straightforward and won't take long.

  • 0 in reply to Lorenzo Marcantonio76
    Expert 2410 points

    Sorry, your post still isn't readable. Are you posting using the normal reply box on the forum, or some other method?

    Try using the syntax highlighter button to insert the objdump output.

    Thanks,

  • 0 in reply to Jozef_Lawrynowicz
    Prodigy 160 points
    The forum doesn't like me… however https://pastebin.com/YWJ83dWw is my previous post. The address seems to refer to a variable, not to code (so I guess the relocation type is wrong). Put a zip with the .o and the Makefile here www.fileconvoy.com/dfl.php. I have no problem rebuilding binutils or even gcc because I'm on linux and I've already have some experience on this.
  • 0 in reply to Lorenzo Marcantonio76
    Expert 2410 points

    Thanks, I have reproduced the relocation overflow with msp430-gcc 8.3.1.25 using the objects form your zip file.

    Unfortunately it is not trivial to check this is fixed with my development version of MSP430-GCC since the LTO objects are not compatible between different versions of GCC (the development version of MSP430-GCC is GCC 9).

    So I will do some more thorough investigation and report back.

    Regards,

  • 0 in reply to Lorenzo Marcantonio76
    Expert 2410 points

    I think that when assembling the .ltrans0.s file, you haven't used the same assembler flags GCC is using when it invokes the assembler. If you build with "-v -Wl,-v" you should be able to see the full invocation of the the "as" program.

    But we can see in the listing close to 0x1a74 is at branch to .L310:

    2477 1a4e 3040 0000            BR      #.L310

    The address of .L310 is 0x1686:

    2204                   .L310:
 2205 1686 B240 FF7F            MOV.W   #32767, &ble_rx_ptr

    0x1a74 - 0x1686 = 0x3c8 == 968.

    The difference between these addresses is small enough that the BR instruction can be relaxed to a JMP.

    The linker must be spotting this and performing the relaxation. However, when other relaxations are performed, the JMP to .L310 goes out of range and you get the relocation overflow.

    This is the bug I have fixed in the development version of MSP430-GCC - the linker did not have the capability of relaxing unconditional JMP instructions back to BR instructions.

    I verified this bug is now fixed by copying the fixed version of the linker into the msp430-gcc 8.3.1.25 installation. When I do this, I can link your project without error.

    Regards,

  • 0 in reply to Jozef_Lawrynowicz
    Prodigy 160 points
    Cool. Probably I forgot some architecture option and it built for an MSP430 and not an MSP430XV2… the binutils development version is the standard gnu upstream or is there some staging repository for the MSP430 toolchain? Thanks for the assistance
  • 0 in reply to Lorenzo Marcantonio76
    Expert 2410 points

    Lorenzo Marcantonio76 said:
    the binutils development version is the standard gnu upstream or is there some staging repository for the MSP430 toolchain? Thanks for the assistance

    Yes just the standard GNU upstream binutils. The fix for this bug is on binutils-2_34-branch, but not in the 2.34 release. The fix is also is on master of course.

    I would recommend using the head of binutils-2_34-branch to build the tools, since it is in a stable state with only bug fixes being added.

    The specific patch that fixes the bug is

    commit 07361958628e74507df1ce2051c935a1a67f7fe9
Author: Jozef Lawrynowicz <jozef.l@mittosystems.com>
Date:   Mon Feb 10 20:33:21 2020 +0000

    MSP430: Enable relaxation of relocs in JMP instructions

    Regards,