Compiler/AM3358: Erroneous ti-cgt-pru_2.1.4 (and 2.1.2): error in JMP and JAL to forward referenced label or register argument

Could this problem have anything at all to do with an improper linker command file? Just a thought. I am using the supplied AM3359_PRU.cmd file.

In addition, please describe exactly how you know the jump instructions operate incorrectly.  What are you looking at?  Precisely how do you go about it?

Thanks and regards,

-George

I have spent the entire day observing the operation of variations of the two instructions JMP and JAL. Find below a snippet of the .lst file demonstration the encoding of several variations of these instructions. Some of the initial inline assembler code is sufficiently functional so that I can write data to PRU SHARED RAM and access this data from the ARM and then visually to a stdio test suite. I am well able to verify code execution at a branch address. No versions of the JMP and JAL instructions execute correctly. I can branch successfully with QBA to the same labels as used with the JMP/JAL tests. The original assembly code executes correctly when assembled with PASM.

     292
     293                                ;*********************************************
     294                                ; CALL .macro dst
     295                                ;       JAL     callReg.w2, dst
     296                                ;       .endm
     297                                ;
     298                                ; Where 'callReg' is defined as 'r3.w2', i.e.
     299                                ;
     300                                ; #define callReg       r3
     301                                ;       %}
     302                                ;*********************************************
     303
     304        ;QBA            IET_CMR0_ISR + 8
     305                                ;--
     306 000001b8 0000002100BC00          JMP             0x2f0
     307                                ;--
     308 000001bc 00000021000000!         JMP             IET_CMR0_ISR
     309                                ;-- above IET_CMR0_ISR = 0x2f0
     310 000001c0 00000020E90000          JMP             regVal
#                                          JMP             r9
     311                                ;-- above regVal = 0x20c
     312 000001c4                         CALL    IET_CMR0_ISR
1        000001c4 000000230000C3!         JAL             callReg.w2, dst
#                                          JAL             r3.w2, IET_CMR0_ISR
PRU Assembler Unix v2.1.4 Sat Jan 21 21:36:25 2017

Tools Copyright (c) 2012-2015 Texas Instruments Incorporated
/home/brendan/ti-cgt-pru_2.1.4/example/PRU_hardI2C_IET_Interrupt.asm PAGE   13

     313                                ;-- above IET_CMR0_ISR = 0x2f0
     314 000001c8                         CALL    0x2f0
1        000001c8 0000002300BCC3          JAL             callReg.w2, dst
#                                          JAL             r3.w2, 0x2f0
     315                                ;--  
     316 000001cc 000000230000C3!         JAL             r3.w2, IET_CMR0_ISR
     317                                ;-- above IET_CMR0_ISR = 0x2f0
     318 000001d0 0000002300BCC3          JAL             r3.w2, 0x2f0
     319                                ;---------------------------------------------

.

.

.

     329 000001f0                 ISR_JMP64_TABLE:
     330 000001f0 00000021000000!         JMP             CORE_LOOP
     331 000001f4 00000021000000!         JMP             CORE_LOOP
     332 000001f8 00000021000000!         JMP             CORE_LOOP
     333 000001fc 00000021000000!         JMP             CORE_LOOP
     334 00000200 00000021000000!         JMP             CORE_LOOP
     335 00000204 00000021000000!         JMP             CORE_LOOP
     336 00000208 00000021000000!         JMP             CORE_LOOP
     337 0000020c 00000021000000!         JMP             IET_CMR0_ISR    ; ISR
     338 00000210 00000021000000!         JMP             CORE_LOOP
     339 00000214 00000021000000!         JMP             CORE_LOOP

Extensive verification activities suggest that an offset of 0x40 (64-bytes) is subtracted from a label argument for the JAL instruction.

For example the instruction:

JAL    r3.w2, MY_LABEL

actually behaves as:

JAL    r3.w2, MY_LABEL - 0x40

What you're showing us is the listing file output by the assembler for the relocatable object file, not the executable file.  According to the PRU Assembly Language Tools User's Guide, the ! relocation indicator character at the end of the opcode stands for an undefined external reference, which means that some of those zero fields are going to be filled in at link time.  See the PRU Assembly Language Tools User's Guide at

http://processors.wiki.ti.com/index.php/TI_Compiler_Information#Compiler_Manuals

So, for instance, the table labeled ISR_JMP64_TABLE has a bunch of instructions with the very same opcode, which is just the opcode for JMP imm, without the actual destination value. As for the instruction at line 306 of the listing, the destination was known at assembly time, so it is present in the opcode, and there is no relocation character.

The listing file alone is not enough to get insight into this issue. We would also need the dump of the relocation table from the object file that ofdpru gives you. However, it would be better to look at the disassembly of the executable file. If you want to be really sure, send us either:

1. The linker map file (linker option --map_file)
2. The executable file (typically named something.out)

or

1. The linker map file (linker option --map_file)
2. The full output of ofdpru -v something.out
3. The full output of dispru simething.out

The JMP instruction is not supposed to subtract anything during execution.  There is a 16-bit field in the JMP imm instruction, and that value is multiplied by 4 to get the actual absolute address.

Brendan Graham said:

As far as I am concerned, I have never expressly taken any actions to relocate any code. All the code in question works flawlessly when assembled with PASM. Use of the TI clpru assembler is only thing that's different here and the only reason for the attempted transition is so that I can make use of the PRU C/C++ compiler.

Well, that's one major difference between pasm and clpru: with clpru you must link the code to make an executable file.  Linking does relocation and placement.

Your clpru command line does include the --run_linker command, so you are linking the program.  You're using the --output_file option, so your executable file is named $build_root/ti-cgt-pru_2.1.4/example/PRU_hardI2C_IET_Interrupt.bin; that's the file we need to examine.

The name of the linker output file is irrelevant; changing the name doesn't change the output type.  The linker produces an object file; usually it is an absolute, executable object file.  PRU only supports ELF, so the magic number should be (in hex) 7f 45 4c 46, or "^?ELF".

Please run ofdpru -v on the .bin file and show us the "Object File Information" section.  It should look like this:

 Object File Information

    File Name:           a.out                  
    Format:              ELF Version 1          
    File Type:           executable file        
    Machine:             TI PRU                 
    Machine Endian:      little endian          
    Entry Point:         0x00005538             
    Vendor:              Texas Instruments, Inc.
    Producer:            Linker                 
    Linker Version:      2.2.0                  
    Number of Sections:  28                     
    File Length:         246508                 
    ELF Class:           32-bit objects         
    ELF e_flags:         0x00000000             

    File Name:           PRU_hardI2C_IET_Interrupt.bin
    Format:              ELF Version 1                
    File Type:           executable file              
    Machine:             TI PRU                       
    Machine Endian:      little endian                
    Entry Point:         0x00000000                   
    Vendor:              Texas Instruments, Inc.      
    Producer:            Linker                       
    Linker Version:      2.1.4                        
    Number of Sections:  148                          
    File Length:         20784                        
    ELF Class:           32-bit objects               
    ELF e_flags:         0x00000000         

Brendan Graham said:

What is the precise meaning and implications of the text "File Offset: 0x00000034"

That is the byte location, in the executable file, where the contents of the .text section begin.  Note this is not the address of .text in PRU memory.  That is indicated by Run Address, which is 0.

Thanks and regards,

-George

In the .ofd file, without specifying any .align directive prior to the initial .text section, or equivalently as

.align 0x0

.text

a file offset of 0x34 is observed as in the following excerpt

<2> ".text"

Load Address: 0x00000000 Run Address: 0x00000000

Size: 0x134 Alignment: 64

Loaded Onto Device: Yes Address Unit Size: 8 bits

File Offset: 0x00000034 # Relocs: 0

Section Type: SHT_PROGBITS Page: 0

ELF sh_flags: 0x00000006 ELF sh_flag: SHF_ALLOC

ELF sh_flag: SHF_EXECINSTR TI ext_flags: 0x0

In the same assembly code .text section the following statements were made

CLREN_INTS:

00000068 LDI r9.w0, 0x0004 ; account for length of SBCO instruction at address 0xec

0000006c LDI r9.w2, 0x55aa

00000070 JAL r3.w2, CLREN_INTR + 0x20 ; the branch instruction under test

; @ call address + “test offset” (0x20)

00000074 SBCO &r9, C28, 4*6, 4 ; instruction @ call address + 0x4

; the “return address” (0x00000074)

. . . some code here

000000cc ADD r9, r9, 4

000000d0 ADD r9, r9, 4

000000d4 ADD r9, r9, 4

000000d8 ADD r9, r9, 4

000000dc ADD r9, r9, 4 ; branch instruction at addr 0x70 jumped here instead!!!

000000e0 ADD r9, r9, 4

000000e4 ADD r9, r9, 4

000000e8 ADD r9, r9, 4

000000ec SBCO &r9, C28, 4*7, 4 ; r9 = 0x55aa0014 written to PRU/ARM shared ram

; let's call the byte count in r9.w0 the “residue”

CLREN_INTR:

000000f0 AND r24, r3, r3

000000f4 SBCO &r3, C28, 4*8, 4 ; r3 = 0x002a0000 written to PRU/ARM shared ram

; r3 = “actual return address” = (call address+0x4)/0x4

000000f8 AND r9, r24, r24

000000fc AND r9, r24, r24

00000100 AND r9, r24, r24

00000104 AND r9, r24, r24

00000108 AND r9, r24, r24

0000010c AND r9, r24, r24

00000110 AND r9, r24, r24 ; branch instruction at addr 0x70 should have jumped here!!!

00000114 AND r9, r24, r24

00000118 AND r9, r24, r24

0000011c AND r9, r24, r24

00000120 AND r9, r24, r24

00000124 AND r9, r24, r24

00000128 AND r9, r24, r24

0000012c AND r3, r24, r24

00000130 JMP r3.w2

The results of the preceeding apparently erroneous example code can be explained with the following argument. The branch instruction at address 0x70 is expected to branch to address 0x110 but it instead branches to address 0xdc. We know this because the SBCO instruction at address 0xec writes the byte count 0x14 (0x14/4 = 5 instructions), computed beginning at the address of the PC after the branch instruction executes at address 0x70, up until the label CLREN_INTR is written to ARM shared memory and output to stdio The actual return address 0x2a stored in register r3.w2 is written to ARM shared memory and output to stdio. Therefore the following calculation must be true:

file offset = test offset + residue

0x34 = 0x20 + 0x14

If the .text section is explicitly aligned to the offset 0x40 for instance, as

.align 0x40

.text

then the calculation is verified to also be true.

return address = actual return address + file offset

0x2d*4 (0xb4) = 0x74 + 0x40

The function "prussdrv_pru_write_memory(pru_ram_id, 0, code, codelen)" is always loading the binary executable from offset '0', i.e. the beginning of the file. PASM must be writing a binary with NO offset always. So the question remains as to why clpru does not remove a known offset into the binary file. But this is the job of the linker, to properly resolve symbols based on the offset of entry_symbol from the beginning of the binary file. So here again it appears that the clpru linker is deficient.

github.com/.../prussdrv.c

{}

}

Brendan,

The prussdrv user space library (along with the UIO pruss kernel driver) is meant to load the binary format that is output from the PASM tool.

The RemoteProc kernel driver is capable of loading the ELF binaries that are output by the TI C compiler/assembler: http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_and_RPMsg#Remoteproc

See this e2e answer about how to add a resource_table header (required by RemoteProc) into your assembly file :https://e2e.ti.com/support/arm/sitara_arm/f/791/p/447040/1608294#1608294

 See this hands-on lab for an introduction on how to use the RemoteProc driver to load your firmware into the PRU: http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#LAB_4:_Introduction_to_Linux_driver

Jason Reeder

p.s. alternatively there may be a series of steps to convert the ELF binary (from the TI compiler/assembler/linker) into a format that the prussdrv library can use. But any support for prussdrv or PASM will need to come from the BeagleBoard community here: http://beagleboard.org/

Brendan,

Does this correct your issue with the JAL offset? Or does the issue persist?

Jason Reeder