Issues Segregating RTS Library Code

Try running ofd6x on the .out file. Does the section .rts:text show up?

Yes, that's part of the head scratcher that I left out.  First, to answer your question directly, the section shows up:

    1 .rts:text                 0x0080d740 0x0080d740   0x1500    32   Y

For all intents and purposes, the section seems to exist, but when I either load the .out file directly (via JTAG) or create a boot image, the code in the section gets stripped out, but the symbols are still defined.  That's why I am kind of stumped.

Maybe a clue: With the above line, two symbols show up in the map as undefined:

UNDEFED __TI_TLS_INIT_Base
UNDEFED __TI_TLS_INIT_Limit

If I comment out that line in the command file where I group all the rts text sections together, the symbols still don't get defined, but they are not listed as undefined, either, i.e., they don't get used.

Edit:  And these two symbols are declared as undefined regardless:

UNDEFED   __TI_INITARRAY_Base

UNDEFED   __TI_INITARRAY_Limit

So what do all these TI-generated symbols mean?  What are they used for?

Alex said:

but the resulting .out file is missing the code

I'm sure you're right.  But I still would like to know exactly how you determine this code is missing.

Thanks and regards,

-George

Well, the code itself isn't missing, but as I stated in my opening post, the resultant binary image ROM image I flash shrinks from 57032 bytes to 46456 bytes, so something is missing.  And disregarding final ROM image and just loading the out file directly via emulator, the application crashes.  Now, I can spend a day or two or a week tracing the code from _c_int00 onward, but I think I can avoid that if I can determine why the mere act of grouping the rts functions causes the application's memory footprint reduce in size.  The differential is way too large to toss it up to code alignment filling or what not.

Here is an idea to consider.  Compare the global symbols found by the names utility nm6x.  Use the command: nm6x -g file.out .  The -g option limits the output to global symbols.  If functions have gone missing, you'll see that easily.

Thanks and regards,

-George

One additional thought ... Since things seem particularly off here, you may want to follow up by comparing the disassembly with dis6x.  Both dis6x and nm6x are utilities found in the compiler installation.  Do not automatically compare the disassembly; many differences of no consequence will be found.  Just search for the functions you suspect are missing.  If you are correct, you should establish their absence easily enough.

Thanks and regards,

-George

__TI_TLS_INIT_Base starts the list of thread-local objects in your project. There are a few thread-local objects in the library, but you are apparently not using any of them.
__TI_INITARRAY_Base starts the list of static functions to call to construct C++ global objects which have non-trivial constructors.

Are you using the TI hex conversion tool? Are you using a hex conversion tool command file?

As far as I can tell from your ofd6x output, the out file itself is fine. Try running "ofd6x -v a.out" For the section .rts:text, you should see "Section Type: SHT_PROGBITS"; if you do not, there's something wrong.

So I'm not worried about the __TI_INITARRAY stuff as this is a pure C application.

As to your previous question, yes, I'm using hex6x, but no, not using a command file:  just parameters:

%COMMON_TOOLS_DIR%\hex6x -a -boot -e _c_int00 -order L -bootorg=0x80000000 -romwidth=32 -o JewelDspBoot2.bootTable JewelDspBoot2.out

And, yes, the .rts:text section is cited as being extracted/included in the resultant output file ('JewelDspBoot2.bootTable').

I got side-tracked, so I am only now getting to your great suggestion about using nm6x to determine what is missing.  As far as the above "ofd6x -v" suggestion, things look to be in order:

   <1> ".rts:text"

      Load Address:        0x0080d740         Run Address:        0x0080d740  

      Size:                0x1500             Alignment:          32          

      Loaded Onto Device:  Yes                Address Unit Size:  8 bits      

      File Offset:         0x00008ae0         # Relocs:           0            

      Section Type:        SHT_PROGBITS       ELF sh_flags:       0x00000006  

      ELF sh_flag:         SHF_ALLOC          ELF sh_flag:        SHF_EXECINSTR

      TI ext_flags:        0xa                TI ext_flag:        TI_SHF_RETAIN

      TI ext_flag:         TI_SHF_RETAINREFS                                  

---

 

So I think at this point, it's probably safe to assume the RTS code itself is fine, but now it's a matter of figuring out why pulling out and grouping its .text sections causes the linker to remove something else.   I'll do the nm6x exercise.

(So I deleted my previous response because my findings were incorrect.)

Long story short, I reverted my CCS project file, i.e., my project settings, and now everything seems to work. The only setting I knowingly changed was my platform. (I created a new one; before, we were just using your default evm6678 one.) After reverting back and seeing it work again, I changed back to my custom platform, did a clean rebuild, and it still worked. Obviously, I must have accidentally changed something else, but sadly, I don't know what it was.

Anyway, thanks for trying to help!  As always, it's much appreciated!