• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 97 subscribers
  • Views 1658 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.

creating output section ".printf" without a SECTIONS specification

Brad Griffis
Guru*** 125430 points
Other Parts Discussed in Thread: TMS320VC5502

TMS320VC5502
BIOS 5.41.07.24
Codegen 4.3.6

I see an issue where the generated linker command file does not have any kind of statement to deal with ".printf" and so I get this warning from the linker:

creating output section ".printf" without a SECTIONS specification

This particular project was migrated all the way back from BIOS 4.90 using the cdb2tcf.exe tool.  It seemed to go fine, but I thought I'd mention just in case!

In their old BIOS 4.90 project they see the following in the generated linker command file:

       .printf (COPY): {} > SDRAM
       
        /* LOG_system buffer */
        .LOG_system$buf: block(0x20000) align = 0x0 fill = 0xffff {} > SDRAM
       
        /* trace buffer */
        .trace$buf: block(0x20000) align = 0x40 fill = 0xffff {} > SDRAM

However, in their new code they only see the following:

  /* LOG_system buffer */
        .LOG_system$buf: block(0x20000) align = 0x0 {} > SDRAM PAGE 0

        /* trace buffer */
        .trace$buf: block(0x20000) align = 0x40 {} > SDRAM PAGE 0

Any idea what could be the issue?  Is there a tcf setting that would cause the generated linker command file not to have a printf allocation?

Thanks,
Brad

 

  • 0
    TI__Mastermind 20805 points

    Brad --

    This is strange.   I just built sample app for evm5505 and I see the .printf section in the .cmd file:

     

            GROUP {
             .const: {}
             .printf (COPY): {}
            } > DARAM PAGE 0

            /* LOG_system buffer */
            .LOG_system$buf: block(0x20000) align = 0x400 {} > DARAM PAGE 0

            /* trace buffer */
            .trace$buf: block(0x20000) align = 0x40 {} > DARAM PAGE 0TM

    Can you send across the .tcf file?  If you are using CCSv3, the build should also leave a .cdb file artifact. At least as far as I remember.   CCSv4 appears to remove this file (which is OK since it's not really used for anything except perhaps debugging an issue like this).  If you've got the .cdb, that might help.  

    I'm still digging ...

    -Karl-

     

  • 0 in reply to Karl Wechsler
    TI__Guru*** 125430 points

    I've requested the tcf from the customer.  I agree it is strange.  I have multiple c5000 projects, including one for the 5502 but I see the same thing as you do.

    By the way, in CCS 4.x all the generated files (cmd, cdb, etc) all appear in the folder corresponding to the build config (i.e. Debug/Release).  I still see the cdb files "hanging around" in the latest releases.

  • 0 in reply to Brad Griffis
    TI__Guru*** 125430 points

    Ok, I reproduced the issue and it's actually very simple (embarrassingly!).  The "issue" was caused by the fact that under System -> MEM -> Properties -> Compiler Sections that had checked the box "User .cmd file for Compiler Sections".  Here's a screenshot:

    I can see it specifically mentions .printf inside here, so I guess it's no mystery why the linker command file would not have it with this option selected!

    However, my question is why we include ".printf" in this area of Compiler Sections.  The ".printf" section is not a compiler section (I think .cio would be the closest).  As far as I can tell this .printf section is a (clever) creation of BIOS, which is why it normally is listed as a copy section.  At this point I don't think I would want you to change the behavior because there may be users that depend on this behavior.  I was curious why we did it this way though...

    Thanks for looking into the issue, Karl.  Sorry it was kind of a dud!  :)

    Brad

     

  • 0 in reply to Brad Griffis
    TI__Guru*** 125430 points

    One other note....  It looks like this behavior changed from BIOS 4.90 to BIOS 5.xx.  In other words, the .printf section was spiked out on its own in 4.90 and this "issue" only appeared in 5.xx.  Perhaps that's something to be aware of when people migrate (if anyone is left!!!).  :)