• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 52 subscribers
  • Views 736 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.

Section size larger than actual COFF file size?

Richard Zuber
Prodigy 210 points

Hello,

I am working on a COFF file parser that will be used to help load our code on to our C6472 part. The data for each section is read in by reading the number of bytes (defined in the section header) from the file pointer offset in the file (also defined in the section header) as per SPRAAO8.

My test input defines a large amount of data in a section ddr_heap (as seen by using ofd6x.exe):

id name                      load addr  run addr        size align alloc
-- ----                      ---------  --------        ---- ----- -----
 1 $build.attributes         0x00000000 0x00000000      0x21     1   N
 2 xdc.meta                  0x00800000 0x00800000     0x107     8   N
 3 .sysmem                   0x00000000 0x00000000       0x0     1   N
 4 .bss                      0x0085dd20 0x0085dd20      0xac     8   Y
 5 .pinit                    0x00854654 0x00854654       0xc     4   Y
 6 .cinit                    0x00850168 0x00850168    0x44ec     8   Y
 7 .args                     0x0085da00 0x0085da00     0x200     4   Y
 8 .data                     0x00800000 0x00800000       0x0     1   Y
 9 .stack                    0x0085a770 0x0085a770    0x2000     8   Y
10 .text:_c_int00            0x00200100 0x00200100      0x80    32   Y
11 .const                    0x0084a5a8 0x0084a5a8    0x5bba     8   Y
12 .debug_info               0x00000000 0x00000000   0xb9e7a     1   N
13 .debug_line               0x00000000 0x00000000    0xf018     1   N
14 .cio                      0x0085dc00 0x0085dc00     0x120     4   Y
15 .rtdx_data                0x00854680 0x00854680    0x40ec   128   Y
16 ll2_heap                  0x10200100 0x10200100   0x33e00   128   Y
17 .text                     0x00800000 0x00800000   0x24d20    32   Y
18 .far                      0x00824d20 0x00824d20   0x1a484     8   Y
19 .taskStackSection         0x0083f1a8 0x0083f1a8    0xb400     8   Y
20 ddr_heap                  0xe0000000 0xe0000000 0x1f2d580     8   Y
21 .rtdx_text.1              0x00854660 0x00854660      0x20    32   Y
22 .rtdx_text.2              0x0085c780 0x0085c780    0x1080    32   Y
23 .switch                   0x0085ddcc 0x0085ddcc      0x44     4   Y
24 .transferBufferSection    0x00858770 0x00858770    0x1ffc     8   Y
25 hpi_regs                  0x10200000 0x10200000      0x9c     8   Y
26 .vecs                     0x0085d800 0x0085d800     0x200  1024   Y
27 .debug_abbrev             0x00000000 0x00000000     0x865     1   N

The issue is that the .x64P file generated is not as big as the amount indicated by the size (in this example, the file size is ~1.1MB, it would have to be at least ~32MB to initialize that whole section).  Also some (but not by any means all) of the data in this section is statically initialized, so simply skipping the section isn't an option.  The COFF file was generated using code generation tools 7.2.4.

I'm guessing I'm missing some detail defined in the documentation; but any help would be appreciated.

  • 0
    TI__Guru* 84285 points

    I see you have a .cinit section.  Most likely what's going on is that ddr_heap is being created as an uninitialized section, so that section has no raw data in the COFF file.  The initializers for that section are encoded in .cinit, and will show up when auto-initialization is done during c_int00.

  • 0
    TI__Guru**** 252950 points

    Please show me the lines in your link command file which create the ddr_heap section.  Also show me the lines in the map file which show ddr_heap and everything that contributes to it.

    Thanks and regards,

    -George

  • 0 in reply to Archaeologist
    Prodigy 210 points

    Thanks for the quick reply.  Another thing I did notice since I posted, the file offset to that section is zero.  This matches up with your observation that there is no data for this section.  You are correct looking at c_int00, I see the data I was expecting.