From: SourceForge.net <no...@so...> - 2006-11-10 18:40:36
|
Bugs item #1594347, was opened at 2006-11-10 19:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1594347&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: linker Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: WendelinM (wendelinm) Assigned to: Nobody/Anonymous (nobody) Summary: linkerr when adding harmless array access Initial Comment: Just running make.bat results in 2 error during linker run: ?ASlink-Error-Could not get 11 consecutive bytes in internal RAM for area OSEG. ?ASlink-Error-Could not get 9 consecutive bytes in internal RAM for area OSEG. The error occurs only if the define GENERATE_LINK_ERROR() in subdir/file LCDisplay/display_driver.c is set to "(1)" (enabling two array write accesses at end of file). The error also disappear when removing other (but mostly much bigger) parts of prg. The provided example is the smallest difference i found betweeen fault and run version. Target is a Atmel 89C51CC03 (64kb Flash). Compiler runs on W2K(SP4). Compiler is from yesterday snapshot: SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.6.1 #4467 (Nov 9 2006) (MINGW32) Older version (ie. from Sep19) has the same behaviour. Cause, error occurs only with the huge amount of source, i attached the whole package as it is. Please dont hesitate to contact me, if you have further questions. best regards from germany Michael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1594347&group_id=599 |
From: SourceForge.net <no...@so...> - 2006-11-16 13:37:32
|
Bugs item #1594347, was opened at 2006-11-10 19:40 Message generated for change (Comment added) made by wendelinm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1594347&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: linker Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: WendelinM (wendelinm) Assigned to: Nobody/Anonymous (nobody) Summary: linkerr when adding harmless array access Initial Comment: Just running make.bat results in 2 error during linker run: ?ASlink-Error-Could not get 11 consecutive bytes in internal RAM for area OSEG. ?ASlink-Error-Could not get 9 consecutive bytes in internal RAM for area OSEG. The error occurs only if the define GENERATE_LINK_ERROR() in subdir/file LCDisplay/display_driver.c is set to "(1)" (enabling two array write accesses at end of file). The error also disappear when removing other (but mostly much bigger) parts of prg. The provided example is the smallest difference i found betweeen fault and run version. Target is a Atmel 89C51CC03 (64kb Flash). Compiler runs on W2K(SP4). Compiler is from yesterday snapshot: SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.6.1 #4467 (Nov 9 2006) (MINGW32) Older version (ie. from Sep19) has the same behaviour. Cause, error occurs only with the huge amount of source, i attached the whole package as it is. Please dont hesitate to contact me, if you have further questions. best regards from germany Michael ---------------------------------------------------------------------- >Comment By: WendelinM (wendelinm) Date: 2006-11-16 14:37 Message: Logged In: YES user_id=1639659 Originator: YES option '--stack-auto' or --model-medium' works. unfortunally code is now slower. see discussion on http://sourceforge.net/forum/forum.php?thread_id=1139694&forum_id=1864 Michael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1594347&group_id=599 |
From: SourceForge.net <no...@so...> - 2006-11-16 20:40:22
|
Bugs item #1594347, was opened at 2006-11-10 19:40 Message generated for change (Comment added) made by maartenbrock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1594347&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: linker >Group: non bugs >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: WendelinM (wendelinm) >Assigned to: Maarten Brock (maartenbrock) Summary: linkerr when adding harmless array access Initial Comment: Just running make.bat results in 2 error during linker run: ?ASlink-Error-Could not get 11 consecutive bytes in internal RAM for area OSEG. ?ASlink-Error-Could not get 9 consecutive bytes in internal RAM for area OSEG. The error occurs only if the define GENERATE_LINK_ERROR() in subdir/file LCDisplay/display_driver.c is set to "(1)" (enabling two array write accesses at end of file). The error also disappear when removing other (but mostly much bigger) parts of prg. The provided example is the smallest difference i found betweeen fault and run version. Target is a Atmel 89C51CC03 (64kb Flash). Compiler runs on W2K(SP4). Compiler is from yesterday snapshot: SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.6.1 #4467 (Nov 9 2006) (MINGW32) Older version (ie. from Sep19) has the same behaviour. Cause, error occurs only with the huge amount of source, i attached the whole package as it is. Please dont hesitate to contact me, if you have further questions. best regards from germany Michael ---------------------------------------------------------------------- >Comment By: Maarten Brock (maartenbrock) Date: 2006-11-16 21:40 Message: Logged In: YES user_id=888171 Originator: NO Michael, As you've discovered this is no bug in the linker. You just ran out of memory due to a growing application. Maarten ---------------------------------------------------------------------- Comment By: WendelinM (wendelinm) Date: 2006-11-16 14:37 Message: Logged In: YES user_id=1639659 Originator: YES option '--stack-auto' or --model-medium' works. unfortunally code is now slower. see discussion on http://sourceforge.net/forum/forum.php?thread_id=1139694&forum_id=1864 Michael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1594347&group_id=599 |
From: SourceForge.net <no...@so...> - 2006-11-16 21:47:51
|
Bugs item #1594347, was opened at 2006-11-10 19:40 Message generated for change (Comment added) made by frief You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1594347&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: linker Group: non bugs Status: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: WendelinM (wendelinm) Assigned to: Maarten Brock (maartenbrock) Summary: linkerr when adding harmless array access Initial Comment: Just running make.bat results in 2 error during linker run: ?ASlink-Error-Could not get 11 consecutive bytes in internal RAM for area OSEG. ?ASlink-Error-Could not get 9 consecutive bytes in internal RAM for area OSEG. The error occurs only if the define GENERATE_LINK_ERROR() in subdir/file LCDisplay/display_driver.c is set to "(1)" (enabling two array write accesses at end of file). The error also disappear when removing other (but mostly much bigger) parts of prg. The provided example is the smallest difference i found betweeen fault and run version. Target is a Atmel 89C51CC03 (64kb Flash). Compiler runs on W2K(SP4). Compiler is from yesterday snapshot: SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.6.1 #4467 (Nov 9 2006) (MINGW32) Older version (ie. from Sep19) has the same behaviour. Cause, error occurs only with the huge amount of source, i attached the whole package as it is. Please dont hesitate to contact me, if you have further questions. best regards from germany Michael ---------------------------------------------------------------------- >Comment By: Frieder Ferlemann (frief) Date: 2006-11-16 22:47 Message: Logged In: YES user_id=589052 Originator: NO Hi Michael, it's the printf() that kills you. Use printf_tiny() instead. This should leave you with around 20 bytes of free data memory. I had to do a puzzle to arrive there: I compiled the source under Linux and had to adapt a few places where the code was not portable with respect to filenames. SDCC unfortunately does not warn about them: Differing upper/lower casing of filenames at several places. F.e.: #include "hardwaresettings.h" when the file is named "Hardwaresettings.h" and a "wrong" directory separator: \\ instead of / #include "..\Bitmaps.h" #include "../Bitmaps.h" The second variant will work under Windows too. This is probably a mild afterglow of a hostile grab and change policy of Microsoft:( I'd like to have an option for SDCC to generate a warning for both. I did file a feature request for the file name case mismatch: http://sourceforge.net/tracker/index.php?func=detail&aid=1506882&group_id=599&atid=350599 but I didn't dare to file one for the backslash character. Both issues continue to be a nagging problem for Unix users which still suffer from MS's filename decisions (my personal view). Greetings, Frieder ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2006-11-16 21:40 Message: Logged In: YES user_id=888171 Originator: NO Michael, As you've discovered this is no bug in the linker. You just ran out of memory due to a growing application. Maarten ---------------------------------------------------------------------- Comment By: WendelinM (wendelinm) Date: 2006-11-16 14:37 Message: Logged In: YES user_id=1639659 Originator: YES option '--stack-auto' or --model-medium' works. unfortunally code is now slower. see discussion on http://sourceforge.net/forum/forum.php?thread_id=1139694&forum_id=1864 Michael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1594347&group_id=599 |
From: SourceForge.net <no...@so...> - 2006-11-17 07:37:37
|
Bugs item #1594347, was opened at 2006-11-10 19:40 Message generated for change (Comment added) made by wendelinm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1594347&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: linker Group: non bugs Status: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: WendelinM (wendelinm) Assigned to: Maarten Brock (maartenbrock) Summary: linkerr when adding harmless array access Initial Comment: Just running make.bat results in 2 error during linker run: ?ASlink-Error-Could not get 11 consecutive bytes in internal RAM for area OSEG. ?ASlink-Error-Could not get 9 consecutive bytes in internal RAM for area OSEG. The error occurs only if the define GENERATE_LINK_ERROR() in subdir/file LCDisplay/display_driver.c is set to "(1)" (enabling two array write accesses at end of file). The error also disappear when removing other (but mostly much bigger) parts of prg. The provided example is the smallest difference i found betweeen fault and run version. Target is a Atmel 89C51CC03 (64kb Flash). Compiler runs on W2K(SP4). Compiler is from yesterday snapshot: SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.6.1 #4467 (Nov 9 2006) (MINGW32) Older version (ie. from Sep19) has the same behaviour. Cause, error occurs only with the huge amount of source, i attached the whole package as it is. Please dont hesitate to contact me, if you have further questions. best regards from germany Michael ---------------------------------------------------------------------- >Comment By: WendelinM (wendelinm) Date: 2006-11-17 08:37 Message: Logged In: YES user_id=1639659 Originator: YES @Maarten: thanks a lot for support @Frieder: thanks for your commitment. Sorry for inaccuracy in spelling. variant with printf_tiny works well. But as i understand Maarten correct, i will fall into same pit later, when application grows more (and it will grow). As i understand, any local variable will be placed into ram like a global or static one in default mode. Only on request (ie reentrant option) they are placed on the stack (like by default with opther compiler, but in most cases a little bit slower). Originally i was confused by the mapfile were i guessed the error. The faulty run (which differs very much from ok run) gave: Area Addr Size Decimal Bytes (Attributes) -------------------------------- ---- ---- ------- ----- ------------ OSEG 007D 0002 = 2. bytes (REL,OVR) Value Global -------- -------------------------------- 0000 Lcan_drv_set_msgbyte$idx$1$1 {.......} 0005 Ldisplay_strcpy$sloc1$1$0 0005 _display_strcpy_sloc1_1_0 0007 Lcopy_icon2display_OR$sloc1$1$0 0007 _copy_icon2display_OR_sloc1_1_0 0009 Lschreibe_msg$sloc1$1$0 0009 _schreibe_msg_sloc1_1_0 001F __gptrput_PARM_2 <- here adr placing differ much from ok run 007D __mulint_PARM_2 <- here adr placing differ much from ok run 007D _calculate_digit_radix_1_1 007E _calculate_digit_i_1_1 at this point there was no memory left. The error msg of the linker was also not very helpfull. Ok, thx again for support. Michael ---------------------------------------------------------------------- Comment By: Frieder Ferlemann (frief) Date: 2006-11-16 22:47 Message: Logged In: YES user_id=589052 Originator: NO Hi Michael, it's the printf() that kills you. Use printf_tiny() instead. This should leave you with around 20 bytes of free data memory. I had to do a puzzle to arrive there: I compiled the source under Linux and had to adapt a few places where the code was not portable with respect to filenames. SDCC unfortunately does not warn about them: Differing upper/lower casing of filenames at several places. F.e.: #include "hardwaresettings.h" when the file is named "Hardwaresettings.h" and a "wrong" directory separator: \\ instead of / #include "..\Bitmaps.h" #include "../Bitmaps.h" The second variant will work under Windows too. This is probably a mild afterglow of a hostile grab and change policy of Microsoft:( I'd like to have an option for SDCC to generate a warning for both. I did file a feature request for the file name case mismatch: http://sourceforge.net/tracker/index.php?func=detail&aid=1506882&group_id=599&atid=350599 but I didn't dare to file one for the backslash character. Both issues continue to be a nagging problem for Unix users which still suffer from MS's filename decisions (my personal view). Greetings, Frieder ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2006-11-16 21:40 Message: Logged In: YES user_id=888171 Originator: NO Michael, As you've discovered this is no bug in the linker. You just ran out of memory due to a growing application. Maarten ---------------------------------------------------------------------- Comment By: WendelinM (wendelinm) Date: 2006-11-16 14:37 Message: Logged In: YES user_id=1639659 Originator: YES option '--stack-auto' or --model-medium' works. unfortunally code is now slower. see discussion on http://sourceforge.net/forum/forum.php?thread_id=1139694&forum_id=1864 Michael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1594347&group_id=599 |