My linker created a --HOLE-- (fill = 0)

David McKenzie95190

I have been trying to compile an operational version of an example project.

But there is a problem...

The compiler appears to "compiles" NOP instructions into "--HOLE--" locations that are created when the linker fails to find the source code from the library.

> I expected that the compiler would stop and that the code composer would show an error for the missing link.

map file output - extract:

SECTION ALLOCATION MAP

 output                                  attributes/
section   page    origin      length       input sections
--------  ----  ----------  ----------   ----------------
.pinit     0    003f4000    00000000     UNINITIALIZED

phyRamFuncs 
*          0    003e8000    000013c5     RUN ADDR = 00008c00
                  003e8000    00000900     phy_lin_afe031_f2806x.lib : phy_cfft16i_vcu.obj (phyRamFuncs)
                  003e8900    000001d3                               : phy_cfft16c_256p_vcu.obj (phyRamFuncs)
                  003e8ad3    00000001     --HOLE-- [fill = 0]
                  003e8ad4    0000018f                               : phy_cfft16c_128p_vcu.obj (phyRamFuncs)
                  003e8c63    00000001     --HOLE-- [fill = 0]
                  003e8c64    00000185                               : phy_eqz.obj (phyRamFuncs)

When I look at the disassembler and step my way through the code, I find a link to the missing file

T:/csa_group_emeter/dspsrdc_csa/emeter/dsp_c28x/src/fft/phy_cfft16i_vcu.asm:49:66

Disassembly extract:

0x3EF729:   8F4096D4    MOVL         XAR5, #0x0096d4
0x3EF72B:   A094        MOVL         *+XAR4[AR0], XAR5
0x3EF72C:   76408C00    LCR          $T:/csa_group_emeter/dspsrdc_csa/emeter/dsp_c28x/src/fft/phy_cfft16i_vcu.asm:49:66$
0x3EF72E:   0006        LRETR
          InitPeripheralClocks:
0x3EF72F:   7622        EALLOW

> Is this normal behaviour?

over 13 years ago

0 Archaeologist over 13 years ago

TI__Guru* 84285 points

The linker creates holes to satisfy alignment requirements. In this case, it is creating holes after the phyRamFuncs sections of object files "phy_cfft16c_256p_vcu.obj" and "phy_cfft16c_128p_vcu.obj" because those sections have an odd number of bytes and presumably even alignment. If you use ofd2000 on each of those two object files and look at the section phyRamFuncs, it should show that they have even alignment and odd size. None of this so far is a bug

Which symbol used in phy_cfft16c_256p_vcu.obj should the linker have found in the library? Please change your linker options to generate a map file, and post that here. It should show whether or not the linker found that symbol.

[Edit: I should have been more precise. There is a hole after phy_cfft16c_256p_vcu.obj because phy_cfft16c_128p_vcu.obj has alignment 2, and there is a hole after phy_cfft16c_128p_vcu.obj because phy_eqz.obj has alignment 2. --Archaeologist]

0 David McKenzie95190 over 13 years ago in reply to Archaeologist

Prodigy 100 points

I have a library file that includes the command LCR 0x369ad8, which sends to the code to unused code space.

The pre-compiled library function TF_256P_CFFT is used by the library function "PHY_txInit()" to initialise the tx section of the code.

Under PHY_txInit:, there is a call to the function PHY_rifft16_512p_init: and this calls PHY_cfft16_init, and this crashes the program.

At the library location (TF_256P_CFFT + 0x1c), which is used under the

0x008C22:   EB7F        SUBR         *-SP[63], AH
0x008C23:   5DA6        MOVZ         AR5, @AR6
0x008C24:   76769AD8    LCR          0x369ad8       <--- This command jumps the program to...

util_block_short_offset + 0x35fb16

0x369AD8:   ????????
0x369AD9:   ????????
0x369ADA:   ????????

This code is from the file... T:csa_group_emeter/dspsrdc_csa/emeter/dsp_c28x/src/fft/phy_cfft16i_vcu.asm that has been compiled into the library file.

The initialisation function is described in the header file "phy_tx.h" by fum and updated by S. Yim in 2009.

It is part of the PrimeDevelopmentPackageV6005.

Do you have a fix?

0 Archaeologist over 13 years ago in reply to David McKenzie95190

TI__Guru* 84285 points

I am not at all familiar with that library. I think we will need someone who is familiar with it to enter this discussion.

Your symptom is that the program has a branch to an apparently bogus address. I cannot guess why that might be so; I would need a test case to pursue this issue.

Code Composer Studio™︎

Code Composer Studio forum

My linker created a --HOLE-- (fill = 0)