build information within a library project

E2E_display_name_Mike

We have a .lib file that was created from C674x PSP. I'm trying to figure out how the build was done so it can be recreated. Is there compiler/linker information embedded in the .lib file that can be extracted? I'd like to know what version of the compiler was used and what compile options were used.

As it stands, we can include this library in our application, but if I rebuild the library and then re-link our application, it won't build because the library takes up too much memory - even when I set the library build to the most aggressive settings for reducing memory size. The weird thing is, the default library size that works (e.g. the currently used .lib file) is 163 kB. I can rebuild it such that the size goes down to 132 kB but when I link this in with our application, it won't build because it runs out of memory. My conclusion is that the linking in the rebuilt library is now taking more memory than the default build.

So, ideally I'd like to somehow find out what compile settings were used on our default .lib file. Or just figure out how to re-build the .lib file so that it will take up the same or less memory versus our default .lib build.

Also, is there a compile/link option we can set for archive builds that will log all the settings used to build the library?

thanks,

Mike

over 14 years ago

0 Archaeologist over 14 years ago

TI__Guru* 84225 points

You can extract the version of the assembler used to build the library member object files by running ofd6x over the library archive. The version of the assembler will correspond to the version of the compiler used to build the library. Most command-line options are not recorded explicitly in the object file.

What is it that is running out of memory? Is your desktop machine running out of memory, or is the program too big for the target you are compiling for?

The size of the library archive is not a good indicator of how big its target footprint is; it contains meta-information like debugging information and uninitialized sections which can be much larger on the target than in the archive.

0 E2E_display_name_Mike over 14 years ago in reply to Archaeologist

Expert 1700 points

thanks for the response.

Archaeologist said:
What is it that is running out of memory? Is your desktop machine running out of memory, or is the program too big for the target you are compiling for?

The linker operation fails because code can no longer be placed in IRAM whereas previoiusly it all fit in IRAM. It's not a windows crash.

Your suggestion of is ofd6x is good, except we didn't put .obj files in our source control. Just the .lib file. I'll try and build with different combinations to see what makes it build. What options should I use to reduce memory usage in the application linking in the library?

thanks,

Mike

0 Archaeologist over 14 years ago in reply to E2E_display_name_Mike

TI__Guru* 84225 points

Mike said:

Your suggestion of is ofd6x is good, except we didn't put .obj files in our source control. Just the .lib file. I'll try and build with different combinations to see what makes it build. What options should I use to reduce memory usage in the application linking in the library?

A library is just an archive of object files; your object files are intact inside the archive, and ofd6x can read them.

Try using the -ms compiler option to favor optimizing for smaller code size. You should probably use optimization as well, even though some optimizations can increase code size. The idea is -ms tries to keep that under control.

See http://processors.wiki.ti.com/index.php/C6000_Compiler:_Recommended_Compiler_Options

What sort of factor increase in code footprint are you seeing? Is it right on the edge, or something like 2x?

0 E2E_display_name_Mike over 14 years ago in reply to Archaeologist

Expert 1700 points

This is all good help. I ran ofd6x on the original and re-built lib files. Both use compiler 6.1.12. I still need to rearrange things to see what the footprint differences are. But one thing that jumps out is the size of the .far sections. The re-built lib is much bigger. Why is this?

Here is cut/paste from the of6dx output:

original .lib file:

     7 .const                    0x00000000 0x00000000  0x10c     4   Y  
     8 .far                      0x00000000 0x00000000 0x1b08     4   Y  
     9 .text:_mcaspMdUnBindDev   0x00000000 0x00000000   0x60    32   Y  

rebuilt .lib file:
     7 .const                    0x00000000 0x00000000  0x10c     4   Y  
     8 .far                      0x00000000 0x00000000 0x637c     8   Y  
     9 .text:_mcaspMdUnBindDev   0x00000000 0x00000000   0x60    32   Y  
I'll try and rearrange some memory so the project builds and tell you what the footprint difference is.
thanks.

0 Archaeologist over 14 years ago in reply to E2E_display_name_Mike

TI__Guru* 84225 points

".far" is for data, so this is not a code size issue. Is there a corresponding drop in size for the ".bss" section? If yes, then it's being compiled for a different data memory model.

Whether data is placed in ".far" or ".bss" depends on the memory model. See http://processors.wiki.ti.com/index.php/C6000_Memory_models

0 E2E_display_name_Mike over 14 years ago in reply to Archaeologist

Expert 1700 points

No. bss is the same. I'll cut/paste the first lines of output of ofd6x run on each library. .far still takes up space in the memory map. IRAM contains code and data so I'm pretty sure now the reason the link can't place the re-built library in memory is that the .far section is too big for IRAM. Any other suggestions why .far is so much bigger on the re-built library? I can attach the whole ofdx6 output files if that will help.

original lib output of ofd6x:

ARCHIVE: ti.pspiom.mcasp_3_3.lib

OBJECT FILE:  Mcasp.obj

 Object File Information

    File Name:                 Mcasp.obj                
    Format:                    TI-COFF Version 2        
    File Type:                 relocatable file         
    Time Stamp:                Mon Jul 12 14:45:27 2010 
    Machine:                   TI C6x                   
    Machine Endian:            little endian            
    Entry Point:               0x00000000               
    Vendor:                    Texas Instruments, Inc.  
    Producer:                  Assembler                
    Assembler Version:         6.1.12                   
    Number of Sections:        60                       
    File Length:               88742                    
    File Offset in Archive:    1008                     
    Symbol Table File Offset:  0x00012d39               
    String Table File Offset:  0x00014db5               
    TI-COFF f_flags:           0x00000190               
    CPU Generation:            C6740                    
    Control Data Endian:       little endian            

 Section Information

    id name                      load addr  run addr     size align alloc
    -- ----                      ---------  --------     ---- ----- -----
     1 $build.attributes         0x00000000 0x00000000   0x21     1   N  
     2 .text                     0x00000000 0x00000000    0x0     1   Y  
     3 .data                     0x00000000 0x00000000    0x0     1   Y  
     4 .bss                      0x00000000 0x00000000    0x4     4   Y  
     5 .debug_info               0x00000000 0x00000000 0x7a53     1   N  
     6 .cinit                    0x00000000 0x00000000   0x3c     8   Y  
     7 .const                    0x00000000 0x00000000  0x10c     4   Y  
     8 .far                      0x00000000 0x00000000 0x1b08     4   Y  
     9 .text:_mcaspMdUnBindDev   0x00000000 0x00000000   0x60    32   Y  
    10 .text:_mcaspWriteChanS... 0x00000000 0x00000000   0xe0    32   Y  
    11 .text:_mcaspWriteUserD... 0x00000000 0x00000000   0xe0    32   Y  
    12 .text:_Mcasp_localGetN... 0x00000000 0x00000000   0x20    32   Y  

re-built lib output of ofd6x:

ARCHIVE: ti.pspiom.mcasp_3_3.lib

OBJECT FILE:  Mcasp.obj

 Object File Information

    File Name:                 Mcasp.obj                
    Format:                    TI-COFF Version 2        
    File Type:                 relocatable file         
    Time Stamp:                Thu Dec 02 08:37:18 2010 
    Machine:                   TI C6x                   
    Machine Endian:            little endian            
    Entry Point:               0x00000000               
    Vendor:                    Texas Instruments, Inc.  
    Producer:                  Assembler                
    Assembler Version:         6.1.12                   
    Number of Sections:        60                       
    File Length:               90067                    
    File Offset in Archive:    1008                     
    Symbol Table File Offset:  0x000131c4               
    String Table File Offset:  0x000152e2               
    TI-COFF f_flags:           0x00000190               
    CPU Generation:            C6740                    
    Control Data Endian:       little endian            

 Section Information

    id name                      load addr  run addr     size align alloc
    -- ----                      ---------  --------     ---- ----- -----
     1 $build.attributes         0x00000000 0x00000000   0x21     1   N  
     2 .text                     0x00000000 0x00000000    0x0     1   Y  
     3 .data                     0x00000000 0x00000000    0x0     1   Y  
     4 .bss                      0x00000000 0x00000000    0x4     4   Y  
     5 .debug_info               0x00000000 0x00000000 0x7bd8     1   N  
     6 .cinit                    0x00000000 0x00000000   0x3c     8   Y  
     7 .const                    0x00000000 0x00000000  0x10c     4   Y  
     8 .far                      0x00000000 0x00000000 0x637c     8   Y  
     9 .text:_mcaspMdUnBindDev   0x00000000 0x00000000   0x60    32   Y  
    10 .text:_mcaspWriteChanS... 0x00000000 0x00000000   0xe0    32   Y  
    11 .text:_mcaspWriteUserD... 0x00000000 0x00000000   0xe0    32   Y  
    12 .text:_Mcasp_localGetN... 0x00000000 0x00000000   0x20    32   Y  

thanks,
Mike

0 Archaeologist over 14 years ago in reply to E2E_display_name_Mike

TI__Guru* 84225 points

Is that all of the sections for each of these two lists? If so, the total size of all data sections is a lot larger in the re-build, which typically does not happen by changing compiler options.

The most likely cause is a change in the source code, such as a buffer defined with a different length, possibly through command line defines. Could you characterize what kind of global data the source file has?

0 E2E_display_name_Mike over 14 years ago in reply to Archaeologist

Expert 1700 points

There are some sub-sections of .text, but you're point is well taken. Something in the rebuild is picking up a lot more data (e.g. variables). I need to check previous revisions to see what could have caused this. This library is the McASP PSP for C674x so it has a lot of globals. Let me spend some time trying to run this down. I'll post my results.

thanks,

Mike

0 George Mock over 14 years ago in reply to E2E_display_name_Mike

TI__Guru**** 244300 points

I have an idea of how you can quickly find which object file(s) contribute the increase in the size of .far. The cg_xml package includes a script named sectti. That script can, among other things, output data on the sections found in library files in .csv format. A command similar to this would collect size data on .far sections ...

$ ofd6x -x --xml_indent=0 --obj_display=none,sections,header,segments name.lib \ 
   | sectti.exe -c | fgrep '.far'
Reading from stdin ...
rts64plus.lib,ecvt.obj,.far,UDATA,100
rts64plus.lib,exit.obj,.far,UDATA,12
rts64plus.lib,fcvt.obj,.far,UDATA,400
rts64plus.lib,gsmvars.obj,.far,UDATA,8
rts64plus.lib,memory.obj,.far,UDATA,8
rts64plus.lib,pprof_user.obj,.far,UDATA,4
...

Then use Excel to process that csv data in a manner similar to how code size data is processed in this Wiki article.

Thanks and regards,

-George

0 E2E_display_name_Mike over 14 years ago in reply to George Mock

Expert 1700 points

Thanks to both of you for the help. The problem was a #define in the source code that would compile out unneeded buffers and code. This was not getting #defined in the re-build.

All this feedback has been helpful and will be useful tools as we try and further characterize and optimize code usage.

thanks!

Mike

Code Composer Studio™︎

Code Composer Studio forum

build information within a library project