Upgrading Code Gen tools from 4.1.3 to 5.0.2 gives me 10x bigger object files in debug

Which processor family?  C6000?

The most likely explanation is that the older compiler uses Stabs debug format, and the newer compiler uses Dwarf debug format.  Dwarf debug format provides many advantages.  But one disadvantage is object file size goes up.

Please be more specific about what you mean by "we can't debug now."  One possible workaround is to go back to Stabs debug format by using --symdebug:coff instead of -g.

Thanks and regards,

-George

Opps, sorry for the lack of info.  It's the C2000 family on a F2812 chip. 

I took a look at the command line help options for the v4.1.3 and here is what they say about the Debug Options:

Symbolic Debug Options:
  -g                   Full symbolic debug
  --symdebug:coff      Full symbolic debug (COFF, deprecated)
  --symdebug:dwarf     Full symbolic debug (same as -g)
  --symdebug:none      Suppress all symbolic debug generation
  --symdebug:profile_coff
                       Function profile debug (COFF, deprecated)
  --symdebug:skeletal  Symbolic debug for program analysis (default)

So it looks like the old tools was dwarf already.

Is there somebody I can send an example listing file of one the object for both build tools for a quick look?

Thanks in Advance,

Francis

I can confirm that Dwarf is the default format for v4.1.3 tools.  So, that alone is not the source of the size difference.

In my experiments, v5.0.2 object files are somewhat larger than v4.1.3, but nothing approaching 10x bigger.  Please run this experiment and post the results here.  You can use the object file display (OFD) utility to expose lots of information in an object file.  In this case, we just want to compare the sizes of all the sections.  For an object file that has a 10x difference, run this OFD command on the v4.1.3 and v5.0.2 versions of the file:

% ofd2000 --obj_display=none,sections file.obj

Note you have to use the v5.0.2 OFD.  The older OFD doesn't support those options.  It is OK to use a new OFD on older object files.  This command dumps out summary information for each section, including the size.  Once we know which sections have the biggest difference, we can investigate further.

Thanks and regards,

-George

Hi George,

I've pasted the output below, it's looks the .debug_info section that's causing the problem:

ofd2000.exe --obj_display=none,sections Rms_New.obj

OBJECT FILE:  Rms_New.obj

 Section Information

    id name                      load addr  run addr      size align alloc
    -- ----                      ---------  --------      ---- ----- -----
     1 .text                     0x00000000 0x00000000   0x1b0     1   Y
     2 .data                     0x00000000 0x00000000     0x0     1   Y
     3 .bss                      0x00000000 0x00000000     0x0     1   Y
     4 .debug_info               0x00000000 0x00000000 0x3d81d     1   N
     5 .cinit                    0x00000000 0x00000000    0x74     1   Y
     6 .ebss                     0x00000000 0x00000000   0x150     2   Y
     7 .econst                   0x00000000 0x00000000    0x9f     2   Y
     8 autoinit                  0x00000000 0x00000000     0x2     1   Y
     9 .debug_frame              0x00000000 0x00000000   0x147     1   N
    10 .debug_line               0x00000000 0x00000000   0x1a2     1   N
    11 .debug_abbrev             0x00000000 0x00000000   0x20e     1   N

ofd2000.exe --obj_display=none,sections Rms_Old.obj

OBJECT FILE:  Rms_Old.obj

 Section Information

    id name                      load addr  run addr     size align alloc
    -- ----                      ---------  --------     ---- ----- -----
     1 .text                     0x00000000 0x00000000  0x1b0     1   Y
     2 .data                     0x00000000 0x00000000    0x0     1   Y
     3 .bss                      0x00000000 0x00000000    0x0     1   Y
     4 .cinit                    0x00000000 0x00000000   0x74     1   Y
     5 .ebss                     0x00000000 0x00000000  0x150     2   Y
     6 .econst                   0x00000000 0x00000000   0x9f     2   Y
     7 autoinit                  0x00000000 0x00000000    0x2     1   Y
     8 .debug_abbrev             0x00000000 0x00000000  0x1d1     1   N
     9 .debug_info               0x00000000 0x00000000 0x1c6d     1   N
    10 .debug_line               0x00000000 0x00000000  0x135     1   N
    11 .debug_frame              0x00000000 0x00000000  0x10a     1   N

Thanks Again,

Francis

Francis,

Can you try the linker option --compress_dwarf to see if the .debug_info size reduces? I think the output files are needed to further analyze this issue.

I tried adding the --compress_dwarf option but with or without the option, the linking is stuck at the message below:

[Linking...] "C:\Program Files\C2000 Code Generation Tools 5.0.2\bin\cl2000" -@"Debug.lkf"
<Linking>

Is there an email I should send the object files?

Thanks,

Francis

You can attach files to a post.  When you are composing a post, look up and to the left.  You'll see "Compose | Options | Preview".  Choose Options.  Attaching a file is pretty straightforward from that point.

Thanks and regards,

-George

Hi George,

Attached is a zip file containing the pair of object files created by the old and newer compiler.

Thanks in Advance,

Francis

The issue is now in our bug tracking system with id SDSCM00036615.  We will examine the files to determine why there is the difference in the .debug_info section.

There is a lot more type information in the 5.0.2 version but there is no obvious reason for this without the source code.  For  example, 5.0.2 include type information for a XINTRUPT_REGS structure and its member types.  This type is not included in the 4.1.3 version.  Any chance different header files were used with the different versions?    Could we see a preprocessed version of the source file?

I'm pretty sure both version are using the same header files.  I'm using Code Composer 3.3 right now and I just changed the code generation tools and been using the same project file.

I'm wondering if it's because the project uses libraries where built using the old gen tool including using the old rts2800_ml.lib.

Anyways, I've attached the PP files for ya'll

Thanks,

Francis

Hello,

i encouter the same issue but project is only 3 times bigger. however, this is big trouble for us as execution times increases greatly (15µs in cgt4.1.3 becomes 26µs in cgt 5.2.6). I could not find any litterature on the different new compilation options available with that cgt. can anyone indicate me how to come to the same situation as in cgt4.1.3?

regards,

Olivier LEMARCHAND  

After some research I can provide some additional information and I have some questions.  The reason for the increased debug size is after 5.0.0 a change was made to keep all user-defined types in the debug info sections, even if they are not referenced.  This is to allow the source debugger to see all the user types.  Can you expand on being unable to debug?  We may need to move this thread to the Code Composer Studio forum to explore why debugging is not working.  The amount of debug information can be reduced by using the --symdebug:skeletal switch instead of the -g switch.  Although this will of course limit the scope of debugging due to reduced information.  Also, does the link step include the -b switch?  If so, can you link and debug when this linker switch is removed?  (The -b linker switch disables type merging in the linker.)