Menu
▾
▴
[sdcc-devel] [ sdcc-Bugs-1909409 ] Pdata in OMF file
|
From: SourceForge.net <no...@so...> - 2008-03-14 04:50:15
|
Bugs item #1909409, was opened at 2008-03-07 01:42 Message generated for change (Comment added) made by jesusc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1909409&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Debugger Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Felix (felix64) Assigned to: Jesus Calvino-Fraga (jesusc) Summary: Pdata in OMF file Initial Comment: Hello, I'm using the Silabs IDE with the SDCC compiler. The problem I have is related to pdata variable type. I contact the Silabs support, which told me that it is a problem in the OMF file (" The problem is with the generation of the OMF file. It is missing the debug type record for the pdata variables. When we are parsing the OMF file, we are unable to find thes records. It is possible that it is in another format, or that we are not interpreting it properly, but our parsing routines work with all of the other toolsets. Regards, Gautam ") I try the following little program //----------------------------------------------------------------------------- // Test pdata debug //----------------------------------------------------------------------------- // // Target: C8051F35x // // Tool chain: SDCC // //----------------------------------------------------------------------------- // Includes //----------------------------------------------------------------------------- pdata int test1; xdata int test2; //----------------------------------------------------------------------------- // MAIN Routine //----------------------------------------------------------------------------- void main (void) { while (1) { test1++; test2++; } } It's works with the Keil, but not with SDCC. With Keil, the pdata test1 is displayed as xdata in silabs watch windows or symbol view table (as test2). With SDCC, test1 variable is not found. Only test2 is OK. I put in attachment the OMF file generated by SDCC. Is that a bug in SDCC or are pdata variables coded in a special way in the SDCC OMF file ? Thank's for you answer Félix SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.7.0 #4818 (May 31 2007) (MINGW32) compile : -c --debug --use-stdout -V / link: --debug --use-stdout -V ---------------------------------------------------------------------- >Comment By: Jesus Calvino-Fraga (jesusc) Date: 2008-03-13 21:50 Message: Logged In: YES user_id=603650 Originator: NO >My local pdata variable had both allocreq and reqv set, but was actually >using the allocated memory in pdata and no registers. Wouldn't that be a different bug then? ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2008-03-13 16:53 Message: Logged In: YES user_id=888171 Originator: NO I think this can be fixed by checking for !sym->allocreq in cdbWriteBasicSymbol() in cdbFile.c line 383 like this: /* CHECK FOR REGISTER SYMBOL... */ if (!sym->allocreq && sym->reqv) { My local pdata variable had both allocreq and reqv set, but was actually using the allocated memory in pdata and no registers. ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2008-03-13 12:08 Message: Logged In: YES user_id=888171 Originator: NO You are right for global variables. And apparently I was looking at local variables. These are treated as living in DATA space instead of XDATA. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2008-03-13 10:42 Message: Logged In: YES user_id=589052 Originator: NO Sorry, my last statement should probably have been: as long as pdata paging register is not changed at runtime. ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2008-03-13 10:25 Message: Logged In: YES user_id=589052 Originator: NO > both test1 and test2 shown in the xdata space this will be OK as long as pdata is located in the lowermost 256 Byte block. ---------------------------------------------------------------------- Comment By: Felix (felix64) Date: 2008-03-13 01:05 Message: Logged In: YES user_id=2029901 Originator: YES For me it's OK. I use SDCC 2.8.0 and Silabs IDE V3.20. I have now both test1 and test2 shown in the xdata space in the IDE. Thank's for the quick fix. ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2008-03-12 16:29 Message: Logged In: YES user_id=603650 Originator: NO This looks like a problem with the SiLabs IDE. A dump of the OMF file clearly shows both test1 and test2 in XDATA: Type=0x12, Length=0034 DEF_TYPE=01 (Public symbols) 00 code 0x0064 00 MAIN 00 xdata 0x0000 00 TEST1 00 xdata 0x0002 00 TEST2 ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2008-03-12 15:40 Message: Logged In: YES user_id=888171 Originator: NO Though the pdata variable is now in the OMF file, it is in the wrong address space. At least the SiLabs IDE thinks the variable is in DATA instead of PDATA or XDATA. ---------------------------------------------------------------------- Comment By: Jesus Calvino-Fraga (jesusc) Date: 2008-03-08 09:23 Message: Logged In: YES user_id=603650 Originator: NO Fixed in revision 5076. This also fixes bug 1629217. ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2008-03-07 08:33 Message: Logged In: YES user_id=888171 Originator: NO This is probably very much related to bug 1629217. http://sourceforge.net/tracker/index.php?func=detail&aid=1629217&group_id=599&atid=100599 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1909409&group_id=599 |