Reply by Jeff Brower July 29, 20032003-07-29
JF-

Thanks for your reply and help. I think it's figured out now. Please see
my earlier mail to Amaresh for details.

-Jeff

>> Does anyone know about "idata" sections in TI's COFF file format?
>
> Never heard about this. I just looked at one of my .out file
> (project using DSP/BIOS) and could not locate any section named
> ".idata". There is well the standard ".data" section, but I suppose
> that this is not the one you are talking about.
>
> Perhaps this is because I have disabled several modules of DSP/BIOS.
> Are you sure that this is not a standard section, defined in some
> DSP/BIOS module for storing its internal data. If yes, I would
> expect this to be listed also in the map file and from there
> you could perhaps track which module declares it.
> Then, it is not a COFF extension, it's just a specific memory
> section for DSP/BIOS.
>
> Additionnaly, it seems that on the C5xxx platform, there is
> an IDATA memory segment defined (-> search for idata on
> dspvillage). As I'm not using this platform, I cannot
> say more on this.
>
> Did I miss something ?
>
> Cheers
>
> J-F



Reply by Jeff Brower July 29, 20032003-07-29
Amaresh-

> I some time back i played with COFF file format.
> As such i didnt come across any document related to
> "idata" section format. The best thing is to findout
> from the initial code of the runtime loadable object
> file. The initial code which loads the consts and
> other section.
> Hope this helps you

Mystery solved last night. They are actually .cinit sections; CCS saves
them for the end of the load. You won't see them unless you have
load-time autoinitialization turned on.

My problem was that our COFF loader STILL did not understand the correct
COFF file format for .cinit sections; it was finding far fewer than it
should. Evidently TI has made some changes in .cinit record formatting
that are not documented, maybe it's a V2 COFF thing, I don't know.
Anyway, our loader is finding all .cinit sections now, and they match
CCS's ".idata" sections, so I'm Ok with that.

Thanks for your help Amaresh.

-Jeff

> --- Jeff Brower <> wrote:
>>
>>
>> Does anyone know about "idata" sections in TI's COFF
>> file format? When
>> CCS loads a COFF file, at the end it also loads
>> sections that appear to be
>> in addition to what's documented in the C6xxx COFF
>> file format. I.e. not
>> cinit, not .const, not .data, etc. but in addition
>> to those. We're trying
>> to figure out how to extract these from the COFF
>> file and load them.
>>
>> One clue: if we look at the addresses that go past
>> when CCS is loading
>> idata sections, then check memory at those
>> addresses, we can see a number
>> of symbols, things like cleanupptr, dtors, lock,
>> unlock, etc. These
>> appear to be CSL and/or DSP/BIOS symbols and they
>> are in fact in the COFF
>> file, at the tail end near the symbol table... but
>> how to deal with any
>> data associated with them?
>>
>> One of our engineers believes this is some COFF
>> formatting that has been
>> added to support DSP/BIOS but is not yet documented.
>>
>> Jeff Brower
>> system engineer
>> Signalogic
>>
>> _____________________________________
>> Note: If you do a simple "reply" with your email
>> client, only the author of this message will receive
>> your answer. You need to do a "reply all" if you
>> want your answer to be distributed to the entire
>> group.
>>
>> _____________________________________
>> About this discussion group:
>>
>> To Join: Send an email to
>>
>>
>> To Post: Send an email to
>>
>> To Leave: Send an email to
>>
>>
>> Archives: http://www.yahoogroups.com/group/c6x
>>
>> Other Groups: http://www.dsprelated.com
>>
>>
>> ">http://docs.yahoo.com/info/terms/
>>
> > __________________________________ > _____________________________________
> Note: If you do a simple "reply" with your email client, only the author
> of this message will receive your answer. You need to do a "reply all" if
> you want your answer to be distributed to the entire group.
>
> _____________________________________
> About this discussion group:
>
> To Join: Send an email to
>
> To Post: Send an email to
>
> To Leave: Send an email to
>
> Archives: http://www.yahoogroups.com/group/c6x
>
> Other Groups: http://www.dsprelated.com > ">http://docs.yahoo.com/info/terms/ >




Reply by Amaresh patil July 29, 20032003-07-29
Hi Jeff,
I some time back i played with COFF file format.
As such i didnt come across any document related to
"idata" section format. The best thing is to findout
from the initial code of the runtime loadable object
file. The initial code which loads the consts and
other section.
Hope this helps you

regards
Amaresh

--- Jeff Brower <> wrote:
>
>
> Does anyone know about "idata" sections in TI's COFF
> file format? When
> CCS loads a COFF file, at the end it also loads
> sections that appear to be
> in addition to what's documented in the C6xxx COFF
> file format. I.e. not
> cinit, not .const, not .data, etc. but in addition
> to those. We're trying
> to figure out how to extract these from the COFF
> file and load them.
>
> One clue: if we look at the addresses that go past
> when CCS is loading
> idata sections, then check memory at those
> addresses, we can see a number
> of symbols, things like cleanupptr, dtors, lock,
> unlock, etc. These
> appear to be CSL and/or DSP/BIOS symbols and they
> are in fact in the COFF
> file, at the tail end near the symbol table... but
> how to deal with any
> data associated with them?
>
> One of our engineers believes this is some COFF
> formatting that has been
> added to support DSP/BIOS but is not yet documented.
>
> Jeff Brower
> system engineer
> Signalogic
>
> _____________________________________
> Note: If you do a simple "reply" with your email
> client, only the author of this message will receive
> your answer. You need to do a "reply all" if you
> want your answer to be distributed to the entire
> group.
>
> _____________________________________
> About this discussion group:
>
> To Join: Send an email to > To Post: Send an email to
>
> To Leave: Send an email to > Archives: http://www.yahoogroups.com/group/c6x
>
> Other Groups: http://www.dsprelated.com > ">http://docs.yahoo.com/info/terms/


__________________________________



Reply by jfbuggen July 29, 20032003-07-29
Hello Jeff,

> Does anyone know about "idata" sections in TI's COFF file format?

Never heard about this. I just looked at one of my .out file
(project using DSP/BIOS) and could not locate any section named
".idata". There is well the standard ".data" section, but I suppose
that this is not the one you are talking about.

Perhaps this is because I have disabled several modules of DSP/BIOS.
Are you sure that this is not a standard section, defined in some
DSP/BIOS module for storing its internal data. If yes, I would
expect this to be listed also in the map file and from there
you could perhaps track which module declares it.
Then, it is not a COFF extension, it's just a specific memory
section for DSP/BIOS.

Additionnaly, it seems that on the C5xxx platform, there is
an IDATA memory segment defined (-> search for idata on
dspvillage). As I'm not using this platform, I cannot
say more on this.

Did I miss something ?

Cheers

J-F




Reply by Jeff Brower July 28, 20032003-07-28


Does anyone know about "idata" sections in TI's COFF file format? When
CCS loads a COFF file, at the end it also loads sections that appear to be
in addition to what's documented in the C6xxx COFF file format. I.e. not
cinit, not .const, not .data, etc. but in addition to those. We're trying
to figure out how to extract these from the COFF file and load them.

One clue: if we look at the addresses that go past when CCS is loading
idata sections, then check memory at those addresses, we can see a number
of symbols, things like cleanupptr, dtors, lock, unlock, etc. These
appear to be CSL and/or DSP/BIOS symbols and they are in fact in the COFF
file, at the tail end near the symbol table... but how to deal with any
data associated with them?

One of our engineers believes this is some COFF formatting that has been
added to support DSP/BIOS but is not yet documented.

Jeff Brower
system engineer
Signalogic