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 |
|
"idata" sections in COFF file
Started by ●July 28, 2003
Reply by ●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 ●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 ●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 ●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 |