Hi Metrowerks gurus, I've disassembled a module in my program where I think there may be a problem. I have include the relevant section below, which has a construction that I cannot understand. Can someone explain it to me? The problems are described inline, starting with ***. 143: char * parseLong(char * str,long * data) parseLong: 00000243 3B PSHD 145: str = skipWhitespace(str); 00000244 EC84 LDD 4,SP 00000246 0734 BSR *+54 ;abs = 027C *** I have to assume that there is a call of skipWhitespace at 027C, but wait until you see what's actually there (below) 146: if ((*str == ',') || !(*str)) { 00000248 2704 BEQ *+6 ;abs = 024E 0000024A E600 LDAB 0,X 0000024C 2610 BNE *+18 ;abs = 025E 147: *data = 0; 0000024E EE80 LDX 0,SP 00000250 C7 CLRB 00000251 87 CLRA 00000252 6C02 STD 2,X 00000254 6C00 STD 0,X 148: if (*str) str++; 00000256 EE84 LDX 4,SP 00000258 E600 LDAB 0,X 0000025A 271C BEQ *+30 ;abs = 0278 0000025C 2017 BRA *+25 ;abs = 0275 151: *data = str8tolong(str); 0000025E B754 TFR X,D 00000260 160000 JSR str8tolong 00000263 160000 JSR ILSEXT 00000266 ED80 LDY 0,SP 00000268 6C42 STD 2,Y 0000026A 6E40 STX 0,Y 152: str+=8; 0000026C EC84 LDD 4,SP 0000026E C30008 ADDD #8 153: str = skipWhitespace(str); 00000271 0709 BSR *+11 ;abs = 027C 154: if (*str == ',') str++; 00000273 2603 BNE *+5 ;abs = 0278 00000275 08 INX 00000276 6E84 STX 4,SP 155: return(str); 00000278 EC84 LDD 4,SP 157: } 0000027A 30 PULX 0000027B 3D RTS *** Here's the apparent call to skipWhitespace (which is at 0135), but the disassembler says it's going to branch to 027d, which would start with the opcode FF and be out of phase with everything else. 0000027C 07FF BSR skipWhitespace ;abs = 027D 0000027E 6C86 STD 6,SP 00000280 B745 TFR D,X 00000282 E600 LDAB 0,X 00000284 C12C CMPB #44 00000286 3D RTS Can someone explain this to a tired, old programmer? Thanks, Paul Johnson |
|
Metrowerks Disassembly Obfuscation - Help!
Started by ●March 25, 2003
Reply by ●March 26, 20032003-03-26
Hello Paul, what you see is called 'common code': the compiler folds togehter pieces of code at to the end of the function. You may use the option -Onf to switch this optimization off. But some questions: how did you generate the listing file? With the decoder (decoding the object file) or decoding the .abs file? I ask because the output looks like generated from the .abs file (say function starts at 0000243, but the presence of relocation/fixup information) 0000027C 07FF BSR skipWhitespace ;abs = 027D says that it is an object file? What you see with the 0x07FF code pattern is the BSR instruction with the offset -1 plus a relocation/fixup which has to be resolved by the linker. So if the listing below is from the .abs file, this is potentially a bug. In case the linker cannot resolve the BSR call, the linker will issue an error. Did you see this? Hope this help, Erich > -----Original Message----- > From: Paul Johnson [mailto:] > Sent: Mittwoch, 26. Marz 2003 01:44 > To: > Subject: [68HC12] Metrowerks Disassembly Obfuscation - Help! > Hi Metrowerks gurus, > > I've disassembled a module in my program where I think there may be a > problem. I have include the relevant section below, which has a > construction that I cannot understand. Can someone explain it to me? The > problems are described inline, starting with ***. > > 143: char * parseLong(char * str,long * data) > parseLong: > 00000243 3B PSHD > 145: str = skipWhitespace(str); > 00000244 EC84 LDD 4,SP > 00000246 0734 BSR *+54 ;abs = 027C > > *** I have to assume that there is a call of skipWhitespace at 027C, but > wait until you see what's actually there (below) > > 146: if ((*str == ',') || !(*str)) { > 00000248 2704 BEQ *+6 ;abs = 024E > 0000024A E600 LDAB 0,X > 0000024C 2610 BNE *+18 ;abs = 025E > 147: *data = 0; > 0000024E EE80 LDX 0,SP > 00000250 C7 CLRB > 00000251 87 CLRA > 00000252 6C02 STD 2,X > 00000254 6C00 STD 0,X > 148: if (*str) str++; > 00000256 EE84 LDX 4,SP > 00000258 E600 LDAB 0,X > 0000025A 271C BEQ *+30 ;abs = 0278 > 0000025C 2017 BRA *+25 ;abs = 0275 > 151: *data = str8tolong(str); > 0000025E B754 TFR X,D > 00000260 160000 JSR str8tolong > 00000263 160000 JSR ILSEXT > 00000266 ED80 LDY 0,SP > 00000268 6C42 STD 2,Y > 0000026A 6E40 STX 0,Y > 152: str+=8; > 0000026C EC84 LDD 4,SP > 0000026E C30008 ADDD #8 > 153: str = skipWhitespace(str); > 00000271 0709 BSR *+11 ;abs = 027C > 154: if (*str == ',') str++; > 00000273 2603 BNE *+5 ;abs = 0278 > 00000275 08 INX > 00000276 6E84 STX 4,SP > 155: return(str); > 00000278 EC84 LDD 4,SP > 157: } > 0000027A 30 PULX > 0000027B 3D RTS > > *** Here's the apparent call to skipWhitespace (which is at 0135), but the > disassembler says it's going to branch to 027d, which would start with the > opcode FF and be out of phase with everything else. > > 0000027C 07FF BSR skipWhitespace ;abs = 027D > 0000027E 6C86 STD 6,SP > 00000280 B745 TFR D,X > 00000282 E600 LDAB 0,X > 00000284 C12C CMPB #44 > 00000286 3D RTS > > Can someone explain this to a tired, old programmer? > > Thanks, > > Paul Johnson > > -------------------- > > ">http://docs.yahoo.com/info/terms/ |
|
Reply by ●March 27, 20032003-03-27
Hi Erich, I could follow the common code optimization, and that makes sense -- it was the BSR -1 that really confused me. I generated this code by right-clicking in in the editor window (in CodeWarrior) and selecting "Disassemble". I did not see any errors related to this, so I assume it was displaying incorrectly but linking correctly. The actual problem that had me on my hands and knees pouring through the assembly code was a much more subtle bug. Every function in the chain that had the failure worked correctly individually, but failed when used in context. I looked for interrupts that might be stepping on data, overflow of input buffers and all sorts of things. The answer was much simpler, but harder to detect. I have a routine -- unsigned long str8tolong(const char * str); -- which expects str to be pointing at an 8 character hexadecimal value and returns an unsigned long. I use it for parsing highly formatted input data. I have several similar routines in one file - strfun.c - that was written, tested and added to a library a long time ago. It turns out that str8tolong was the only one that did NOT have a prototype in the header file. I have apparently never yet used this particular function from that module. As a result, the compiler resorted to implicit parameter declaration, and the return value was assumed (properly) to be of type integer. Since it was then assigned to a long, it was sign-extended to a long, and my troubles began. This bug was darn hard to find. I never noticed the implicit parameter declaration warning in the dozens of meaningless warnings I get on every compile. Is there any way to promote a particular warning to an actual error? Or is there any way to get a particular type of warning to really stand out at compile time? This is a nasty one, and should get more attention. Thanks, Paul Johnson > -----Original Message----- > From: Erich Styger [mailto:] > Sent: Wednesday, March 26, 2003 7:19 AM > To: > Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help! > Hello Paul, > what you see is called 'common code': the compiler folds togehter > pieces of > code > at to the end of the function. > You may use the option -Onf to switch this optimization off. > > But some questions: > how did you generate the listing file? With the decoder (decoding > the object > file) > or decoding the .abs file? > I ask because the output looks like generated from the .abs file (say > function starts > at 0000243, but the presence of relocation/fixup information) > 0000027C 07FF BSR skipWhitespace ;abs = 027D > says that it is an object file? > > What you see with the 0x07FF code pattern is the BSR instruction with the > offset -1 plus > a relocation/fixup which has to be resolved by the linker. > So if the listing below is from the .abs file, this is potentially a bug. > In case the linker cannot resolve the BSR call, the linker will issue an > error. Did you > see this? > > Hope this help, > Erich > > > -----Original Message----- > > From: Paul Johnson [mailto:] > > Sent: Mittwoch, 26. Marz 2003 01:44 > > To: > > Subject: [68HC12] Metrowerks Disassembly Obfuscation - Help! > > > > > > Hi Metrowerks gurus, > > > > I've disassembled a module in my program where I think there may be a > > problem. I have include the relevant section below, which has a > > construction that I cannot understand. Can someone explain it > to me? The > > problems are described inline, starting with ***. > > > > 143: char * parseLong(char * str,long * data) > > parseLong: > > 00000243 3B PSHD > > 145: str = skipWhitespace(str); > > 00000244 EC84 LDD 4,SP > > 00000246 0734 BSR *+54 ;abs = 027C > > > > *** I have to assume that there is a call of skipWhitespace at 027C, but > > wait until you see what's actually there (below) > > > > 146: if ((*str == ',') || !(*str)) { > > 00000248 2704 BEQ *+6 ;abs = 024E > > 0000024A E600 LDAB 0,X > > 0000024C 2610 BNE *+18 ;abs = 025E > > 147: *data = 0; > > 0000024E EE80 LDX 0,SP > > 00000250 C7 CLRB > > 00000251 87 CLRA > > 00000252 6C02 STD 2,X > > 00000254 6C00 STD 0,X > > 148: if (*str) str++; > > 00000256 EE84 LDX 4,SP > > 00000258 E600 LDAB 0,X > > 0000025A 271C BEQ *+30 ;abs = 0278 > > 0000025C 2017 BRA *+25 ;abs = 0275 > > 151: *data = str8tolong(str); > > 0000025E B754 TFR X,D > > 00000260 160000 JSR str8tolong > > 00000263 160000 JSR ILSEXT > > 00000266 ED80 LDY 0,SP > > 00000268 6C42 STD 2,Y > > 0000026A 6E40 STX 0,Y > > 152: str+=8; > > 0000026C EC84 LDD 4,SP > > 0000026E C30008 ADDD #8 > > 153: str = skipWhitespace(str); > > 00000271 0709 BSR *+11 ;abs = 027C > > 154: if (*str == ',') str++; > > 00000273 2603 BNE *+5 ;abs = 0278 > > 00000275 08 INX > > 00000276 6E84 STX 4,SP > > 155: return(str); > > 00000278 EC84 LDD 4,SP > > 157: } > > 0000027A 30 PULX > > 0000027B 3D RTS > > > > *** Here's the apparent call to skipWhitespace (which is at > 0135), but the > > disassembler says it's going to branch to 027d, which would > start with the > > opcode FF and be out of phase with everything else. > > > > 0000027C 07FF BSR skipWhitespace ;abs = 027D > > 0000027E 6C86 STD 6,SP > > 00000280 B745 TFR D,X > > 00000282 E600 LDAB 0,X > > 00000284 C12C CMPB #44 > > 00000286 3D RTS > > > > Can someone explain this to a tired, old programmer? > > > > Thanks, > > > > Paul Johnson > > > > > > > > -------------------- > > > > > > > > ">http://docs.yahoo.com/info/terms/ > > > > > -------------------- > > ">http://docs.yahoo.com/info/terms/ |
|
Reply by ●March 27, 20032003-03-27
Hi Paul, go to the preference panel for the compiler, there is a 'Messages' button, where you can map messages to errors, etc. As the implicit parameter thing is a common programming error, there is even a special compiler option -Wpd which flags this as an error. additionally, if you do not want to set the message mapping using options, you can do it using pragmas in your code (wherever you want, e.g. you can do in a common header file, etc). Check out the #pragma MESSAGE in the manual for this. Example: /* treat C1412: Not a function call, */ /* address of a function, as error */ #pragma MESSAGE ERROR C1412 void f(void); void main(void) { f; /* () is missing, but still legal in C */ /* ERROR because of pragma MESSAGE */ } Thanks, Erich > -----Original Message----- > From: Paul Johnson [mailto:] > Sent: Donnerstag, 27. Marz 2003 15:53 > To: > Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help! > Hi Erich, > > I could follow the common code optimization, and that makes sense > -- it was > the BSR -1 that really confused me. I generated this code by > right-clicking > in in the editor window (in CodeWarrior) and selecting > "Disassemble". I did > not see any errors related to this, so I assume it was displaying > incorrectly but linking correctly. > > The actual problem that had me on my hands and knees pouring through the > assembly code was a much more subtle bug. Every function in the > chain that > had the failure worked correctly individually, but failed when used in > context. I looked for interrupts that might be stepping on data, overflow > of input buffers and all sorts of things. The answer was much > simpler, but > harder to detect. > > I have a routine -- unsigned long str8tolong(const char * str); -- which > expects str to be pointing at an 8 character hexadecimal value and returns > an unsigned long. I use it for parsing highly formatted input > data. I have > several similar routines in one file - strfun.c - that was written, tested > and added to a library a long time ago. It turns out that str8tolong was > the only one that did NOT have a prototype in the header file. I have > apparently never yet used this particular function from that module. > > As a result, the compiler resorted to implicit parameter declaration, and > the return value was assumed (properly) to be of type integer. > Since it was > then assigned to a long, it was sign-extended to a long, and my troubles > began. This bug was darn hard to find. > > I never noticed the implicit parameter declaration warning in the > dozens of > meaningless warnings I get on every compile. Is there any way to > promote a > particular warning to an actual error? Or is there any way to get a > particular type of warning to really stand out at compile time? This is a > nasty one, and should get more attention. > > Thanks, > > Paul Johnson > > > -----Original Message----- > > From: Erich Styger [mailto:] > > Sent: Wednesday, March 26, 2003 7:19 AM > > To: > > Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help! > > > > > > Hello Paul, > > what you see is called 'common code': the compiler folds togehter > > pieces of > > code > > at to the end of the function. > > You may use the option -Onf to switch this optimization off. > > > > But some questions: > > how did you generate the listing file? With the decoder (decoding > > the object > > file) > > or decoding the .abs file? > > I ask because the output looks like generated from the .abs file (say > > function starts > > at 0000243, but the presence of relocation/fixup information) > > 0000027C 07FF BSR skipWhitespace ;abs = 027D > > says that it is an object file? > > > > What you see with the 0x07FF code pattern is the BSR > instruction with the > > offset -1 plus > > a relocation/fixup which has to be resolved by the linker. > > So if the listing below is from the .abs file, this is > potentially a bug. > > In case the linker cannot resolve the BSR call, the linker will issue an > > error. Did you > > see this? > > > > Hope this help, > > Erich > > > > > -----Original Message----- > > > From: Paul Johnson [mailto:] > > > Sent: Mittwoch, 26. Marz 2003 01:44 > > > To: > > > Subject: [68HC12] Metrowerks Disassembly Obfuscation - Help! > > > > > > > > > Hi Metrowerks gurus, > > > > > > I've disassembled a module in my program where I think there may be a > > > problem. I have include the relevant section below, which has a > > > construction that I cannot understand. Can someone explain it > > to me? The > > > problems are described inline, starting with ***. > > > > > > 143: char * parseLong(char * str,long * data) > > > parseLong: > > > 00000243 3B PSHD > > > 145: str = skipWhitespace(str); > > > 00000244 EC84 LDD 4,SP > > > 00000246 0734 BSR *+54 ;abs = 027C > > > > > > *** I have to assume that there is a call of skipWhitespace > at 027C, but > > > wait until you see what's actually there (below) > > > > > > 146: if ((*str == ',') || !(*str)) { > > > 00000248 2704 BEQ *+6 ;abs = 024E > > > 0000024A E600 LDAB 0,X > > > 0000024C 2610 BNE *+18 ;abs = 025E > > > 147: *data = 0; > > > 0000024E EE80 LDX 0,SP > > > 00000250 C7 CLRB > > > 00000251 87 CLRA > > > 00000252 6C02 STD 2,X > > > 00000254 6C00 STD 0,X > > > 148: if (*str) str++; > > > 00000256 EE84 LDX 4,SP > > > 00000258 E600 LDAB 0,X > > > 0000025A 271C BEQ *+30 ;abs = 0278 > > > 0000025C 2017 BRA *+25 ;abs = 0275 > > > 151: *data = str8tolong(str); > > > 0000025E B754 TFR X,D > > > 00000260 160000 JSR str8tolong > > > 00000263 160000 JSR ILSEXT > > > 00000266 ED80 LDY 0,SP > > > 00000268 6C42 STD 2,Y > > > 0000026A 6E40 STX 0,Y > > > 152: str+=8; > > > 0000026C EC84 LDD 4,SP > > > 0000026E C30008 ADDD #8 > > > 153: str = skipWhitespace(str); > > > 00000271 0709 BSR *+11 ;abs = 027C > > > 154: if (*str == ',') str++; > > > 00000273 2603 BNE *+5 ;abs = 0278 > > > 00000275 08 INX > > > 00000276 6E84 STX 4,SP > > > 155: return(str); > > > 00000278 EC84 LDD 4,SP > > > 157: } > > > 0000027A 30 PULX > > > 0000027B 3D RTS > > > > > > *** Here's the apparent call to skipWhitespace (which is at > > 0135), but the > > > disassembler says it's going to branch to 027d, which would > > start with the > > > opcode FF and be out of phase with everything else. > > > > > > 0000027C 07FF BSR skipWhitespace ;abs = 027D > > > 0000027E 6C86 STD 6,SP > > > 00000280 B745 TFR D,X > > > 00000282 E600 LDAB 0,X > > > 00000284 C12C CMPB #44 > > > 00000286 3D RTS > > > > > > Can someone explain this to a tired, old programmer? > > > > > > Thanks, > > > > > > Paul Johnson > > > > > > > > > > > > -------------------- > > > > > > > > > > > > ">http://docs.yahoo.com/info/terms/ > > > > > > > > > > > > > > -------------------- > > > > > > > > ">http://docs.yahoo.com/info/terms/ > > -------------------- ">http://docs.yahoo.com/info/terms/ |
Reply by ●March 27, 20032003-03-27
Paul, Usually compile warnings are not useless, you should try at all cost to write code that does not produce warnings. As was the case with your integer. Sooner or later what you thought was useless warnings will come back to haut you. Michael. ----- Original Message ----- From: "Paul Johnson" <> To: <> Sent: Thursday, March 27, 2003 9:52 AM Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help! > Hi Erich, > > I could follow the common code optimization, and that makes sense -- it was > the BSR -1 that really confused me. I generated this code by right-clicking > in in the editor window (in CodeWarrior) and selecting "Disassemble". I did > not see any errors related to this, so I assume it was displaying > incorrectly but linking correctly. > > The actual problem that had me on my hands and knees pouring through the > assembly code was a much more subtle bug. Every function in the chain that > had the failure worked correctly individually, but failed when used in > context. I looked for interrupts that might be stepping on data, overflow > of input buffers and all sorts of things. The answer was much simpler, but > harder to detect. > > I have a routine -- unsigned long str8tolong(const char * str); -- which > expects str to be pointing at an 8 character hexadecimal value and returns > an unsigned long. I use it for parsing highly formatted input data. I have > several similar routines in one file - strfun.c - that was written, tested > and added to a library a long time ago. It turns out that str8tolong was > the only one that did NOT have a prototype in the header file. I have > apparently never yet used this particular function from that module. > > As a result, the compiler resorted to implicit parameter declaration, and > the return value was assumed (properly) to be of type integer. Since it was > then assigned to a long, it was sign-extended to a long, and my troubles > began. This bug was darn hard to find. > > I never noticed the implicit parameter declaration warning in the dozens of > meaningless warnings I get on every compile. Is there any way to promote a > particular warning to an actual error? Or is there any way to get a > particular type of warning to really stand out at compile time? This is a > nasty one, and should get more attention. > > Thanks, > > Paul Johnson > > > -----Original Message----- > > From: Erich Styger [mailto:] > > Sent: Wednesday, March 26, 2003 7:19 AM > > To: > > Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help! > > > > > > Hello Paul, > > what you see is called 'common code': the compiler folds togehter > > pieces of > > code > > at to the end of the function. > > You may use the option -Onf to switch this optimization off. > > > > But some questions: > > how did you generate the listing file? With the decoder (decoding > > the object > > file) > > or decoding the .abs file? > > I ask because the output looks like generated from the .abs file (say > > function starts > > at 0000243, but the presence of relocation/fixup information) > > 0000027C 07FF BSR skipWhitespace ;abs = 027D > > says that it is an object file? > > > > What you see with the 0x07FF code pattern is the BSR instruction with the > > offset -1 plus > > a relocation/fixup which has to be resolved by the linker. > > So if the listing below is from the .abs file, this is potentially a bug. > > In case the linker cannot resolve the BSR call, the linker will issue an > > error. Did you > > see this? > > > > Hope this help, > > Erich > > > > > -----Original Message----- > > > From: Paul Johnson [mailto:] > > > Sent: Mittwoch, 26. Marz 2003 01:44 > > > To: > > > Subject: [68HC12] Metrowerks Disassembly Obfuscation - Help! > > > > > > > > > Hi Metrowerks gurus, > > > > > > I've disassembled a module in my program where I think there may be a > > > problem. I have include the relevant section below, which has a > > > construction that I cannot understand. Can someone explain it > > to me? The > > > problems are described inline, starting with ***. > > > > > > 143: char * parseLong(char * str,long * data) > > > parseLong: > > > 00000243 3B PSHD > > > 145: str = skipWhitespace(str); > > > 00000244 EC84 LDD 4,SP > > > 00000246 0734 BSR *+54 ;abs = 027C > > > > > > *** I have to assume that there is a call of skipWhitespace at 027C, but > > > wait until you see what's actually there (below) > > > > > > 146: if ((*str == ',') || !(*str)) { > > > 00000248 2704 BEQ *+6 ;abs = 024E > > > 0000024A E600 LDAB 0,X > > > 0000024C 2610 BNE *+18 ;abs = 025E > > > 147: *data = 0; > > > 0000024E EE80 LDX 0,SP > > > 00000250 C7 CLRB > > > 00000251 87 CLRA > > > 00000252 6C02 STD 2,X > > > 00000254 6C00 STD 0,X > > > 148: if (*str) str++; > > > 00000256 EE84 LDX 4,SP > > > 00000258 E600 LDAB 0,X > > > 0000025A 271C BEQ *+30 ;abs = 0278 > > > 0000025C 2017 BRA *+25 ;abs = 0275 > > > 151: *data = str8tolong(str); > > > 0000025E B754 TFR X,D > > > 00000260 160000 JSR str8tolong > > > 00000263 160000 JSR ILSEXT > > > 00000266 ED80 LDY 0,SP > > > 00000268 6C42 STD 2,Y > > > 0000026A 6E40 STX 0,Y > > > 152: str+=8; > > > 0000026C EC84 LDD 4,SP > > > 0000026E C30008 ADDD #8 > > > 153: str = skipWhitespace(str); > > > 00000271 0709 BSR *+11 ;abs = 027C > > > 154: if (*str == ',') str++; > > > 00000273 2603 BNE *+5 ;abs = 0278 > > > 00000275 08 INX > > > 00000276 6E84 STX 4,SP > > > 155: return(str); > > > 00000278 EC84 LDD 4,SP > > > 157: } > > > 0000027A 30 PULX > > > 0000027B 3D RTS > > > > > > *** Here's the apparent call to skipWhitespace (which is at > > 0135), but the > > > disassembler says it's going to branch to 027d, which would > > start with the > > > opcode FF and be out of phase with everything else. > > > > > > 0000027C 07FF BSR skipWhitespace ;abs = 027D > > > 0000027E 6C86 STD 6,SP > > > 00000280 B745 TFR D,X > > > 00000282 E600 LDAB 0,X > > > 00000284 C12C CMPB #44 > > > 00000286 3D RTS > > > > > > Can someone explain this to a tired, old programmer? > > > > > > Thanks, > > > > > > Paul Johnson > > > > > > > > > > > > -------------------- > > > > > > > > > > > > ">http://docs.yahoo.com/info/terms/ > > > > > > > > > > > > > > -------------------- > > > > > > > > ">http://docs.yahoo.com/info/terms/ > > > > > -------------------- > > ">http://docs.yahoo.com/info/terms/ > |
Reply by ●March 27, 20032003-03-27
Also, turn the warning level all the way up. This means enable every warning that the compiler can produce. If your code still compiles without warnings, you are more assured of having created very clean code. (Naturally, there are some execptions to the above. For example, some compilers might gen a warning over formatting issues on otherwise perfectly good code; your mileage will vary.) Karl > -----Original Message----- > From: Mike Burgess [mailto:] > Sent: Thursday, March 27, 2003 11:19 AM > To: > Subject: Re: [68HC12] Metrowerks Disassembly Obfuscation - Help! > Paul, > Usually compile warnings are not useless, you should try at > all cost to > write code that > does not produce warnings. As was the case with your > integer. Sooner or > later > what you thought was useless warnings will come back to haut you. > Michael. > ----- Original Message ----- > From: "Paul Johnson" <> > To: <> > Sent: Thursday, March 27, 2003 9:52 AM > Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help! > > Hi Erich, > > > > I could follow the common code optimization, and that makes > sense -- it > was > > the BSR -1 that really confused me. I generated this code by > right-clicking > > in in the editor window (in CodeWarrior) and selecting > "Disassemble". I > did > > not see any errors related to this, so I assume it was displaying > > incorrectly but linking correctly. > > > > The actual problem that had me on my hands and knees > pouring through the > > assembly code was a much more subtle bug. Every function > in the chain > that > > had the failure worked correctly individually, but failed > when used in > > context. I looked for interrupts that might be stepping on > data, overflow > > of input buffers and all sorts of things. The answer was > much simpler, > but > > harder to detect. > > > > I have a routine -- unsigned long str8tolong(const char * > str); -- which > > expects str to be pointing at an 8 character hexadecimal > value and returns > > an unsigned long. I use it for parsing highly formatted > input data. I > have > > several similar routines in one file - strfun.c - that was > written, tested > > and added to a library a long time ago. It turns out that > str8tolong was > > the only one that did NOT have a prototype in the header > file. I have > > apparently never yet used this particular function from that module. > > > > As a result, the compiler resorted to implicit parameter > declaration, and > > the return value was assumed (properly) to be of type > integer. Since it > was > > then assigned to a long, it was sign-extended to a long, > and my troubles > > began. This bug was darn hard to find. > > > > I never noticed the implicit parameter declaration warning > in the dozens > of > > meaningless warnings I get on every compile. Is there any > way to promote > a > > particular warning to an actual error? Or is there any way to get a > > particular type of warning to really stand out at compile > time? This is a > > nasty one, and should get more attention. > > > > Thanks, > > > > Paul Johnson > > > > > -----Original Message----- > > > From: Erich Styger [mailto:] > > > Sent: Wednesday, March 26, 2003 7:19 AM > > > To: > > > Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help! > > > > > > > > > Hello Paul, > > > what you see is called 'common code': the compiler folds togehter > > > pieces of > > > code > > > at to the end of the function. > > > You may use the option -Onf to switch this optimization off. > > > > > > But some questions: > > > how did you generate the listing file? With the decoder (decoding > > > the object > > > file) > > > or decoding the .abs file? > > > I ask because the output looks like generated from the > .abs file (say > > > function starts > > > at 0000243, but the presence of relocation/fixup information) > > > 0000027C 07FF BSR skipWhitespace ;abs = 027D > > > says that it is an object file? > > > > > > What you see with the 0x07FF code pattern is the BSR > instruction with > the > > > offset -1 plus > > > a relocation/fixup which has to be resolved by the linker. > > > So if the listing below is from the .abs file, this is > potentially a > bug. > > > In case the linker cannot resolve the BSR call, the > linker will issue an > > > error. Did you > > > see this? > > > > > > Hope this help, > > > Erich > > > > > > > -----Original Message----- > > > > From: Paul Johnson [mailto:] > > > > Sent: Mittwoch, 26. Marz 2003 01:44 > > > > To: > > > > Subject: [68HC12] Metrowerks Disassembly Obfuscation - Help! > > > > > > > > > > > > Hi Metrowerks gurus, > > > > > > > > I've disassembled a module in my program where I think > there may be a > > > > problem. I have include the relevant section below, which has a > > > > construction that I cannot understand. Can someone explain it > > > to me? The > > > > problems are described inline, starting with ***. > > > > > > > > 143: char * parseLong(char * str,long * data) > > > > parseLong: > > > > 00000243 3B PSHD > > > > 145: str = skipWhitespace(str); > > > > 00000244 EC84 LDD 4,SP > > > > 00000246 0734 BSR *+54 ;abs = 027C > > > > > > > > *** I have to assume that there is a call of > skipWhitespace at 027C, > but > > > > wait until you see what's actually there (below) > > > > > > > > 146: if ((*str == ',') || !(*str)) { > > > > 00000248 2704 BEQ *+6 ;abs = 024E > > > > 0000024A E600 LDAB 0,X > > > > 0000024C 2610 BNE *+18 ;abs = 025E > > > > 147: *data = 0; > > > > 0000024E EE80 LDX 0,SP > > > > 00000250 C7 CLRB > > > > 00000251 87 CLRA > > > > 00000252 6C02 STD 2,X > > > > 00000254 6C00 STD 0,X > > > > 148: if (*str) str++; > > > > 00000256 EE84 LDX 4,SP > > > > 00000258 E600 LDAB 0,X > > > > 0000025A 271C BEQ *+30 ;abs = 0278 > > > > 0000025C 2017 BRA *+25 ;abs = 0275 > > > > 151: *data = str8tolong(str); > > > > 0000025E B754 TFR X,D > > > > 00000260 160000 JSR str8tolong > > > > 00000263 160000 JSR ILSEXT > > > > 00000266 ED80 LDY 0,SP > > > > 00000268 6C42 STD 2,Y > > > > 0000026A 6E40 STX 0,Y > > > > 152: str+=8; > > > > 0000026C EC84 LDD 4,SP > > > > 0000026E C30008 ADDD #8 > > > > 153: str = skipWhitespace(str); > > > > 00000271 0709 BSR *+11 ;abs = 027C > > > > 154: if (*str == ',') str++; > > > > 00000273 2603 BNE *+5 ;abs = 0278 > > > > 00000275 08 INX > > > > 00000276 6E84 STX 4,SP > > > > 155: return(str); > > > > 00000278 EC84 LDD 4,SP > > > > 157: } > > > > 0000027A 30 PULX > > > > 0000027B 3D RTS > > > > > > > > *** Here's the apparent call to skipWhitespace (which is at > > > 0135), but the > > > > disassembler says it's going to branch to 027d, which would > > > start with the > > > > opcode FF and be out of phase with everything else. > > > > > > > > 0000027C 07FF BSR skipWhitespace ;abs = 027D > > > > 0000027E 6C86 STD 6,SP > > > > 00000280 B745 TFR D,X > > > > 00000282 E600 LDAB 0,X > > > > 00000284 C12C CMPB #44 > > > > 00000286 3D RTS > > > > > > > > Can someone explain this to a tired, old programmer? > > > > > > > > Thanks, > > > > > > > > Paul Johnson > > > > > > > > > > > > > > > > -------------------- > > > > > > > > > > > > > > > > ">http://docs.yahoo.com/info/terms/ > > > > > > > > > > > > > > > > > > > > -------------------- > > > > > > > > > > > > ">http://docs.yahoo.com/info/terms/ > > > > > > > > > > > > > > -------------------- > > > > > > > > ">http://docs.yahoo.com/info/terms/ > -------------------- ">http://docs.yahoo.com/info/terms/ |
Reply by ●March 27, 20032003-03-27
Hi Paul, Let me add my voice to the chorus and explain why I compile with the highest warning level available, and keep the warnings to zero. As others have pointed out, it is easy to prevent a warning from being printed, either by using a #pragma or by adding a cast or redundant assignment. So suppressing the ones that you have determined you are not interested in one by one is pretty easy. The advantage is that when you add new code with that produces a warning, you get told about it by the compiler, and you can easily fix it, because the compiler is pretty good about pointing to exactly where the problem is. Sometimes the problem is obvious and a quick edit will fix it. Sometimes the problem is that you really don't understand some C feature, and you have to study the manuals. In this case you learn something. Sometimes its just the compiler being picky, and you can make it shut up with a quick edit. On the average all of these take much less time than loading the program and debugging it, as you just reported. Keeping the reports of warnings to zero as a matter of policy, saves your time (and frustration)! Steve At 06:52 AM 3/27/2003, you wrote: >Hi Erich, > >I could follow the common code optimization, and that makes sense -- it was >the BSR -1 that really confused me. I generated this code by right-clicking >in in the editor window (in CodeWarrior) and selecting "Disassemble". I did >not see any errors related to this, so I assume it was displaying >incorrectly but linking correctly. > >The actual problem that had me on my hands and knees pouring through the >assembly code was a much more subtle bug. Every function in the chain that >had the failure worked correctly individually, but failed when used in >context. I looked for interrupts that might be stepping on data, overflow >of input buffers and all sorts of things. The answer was much simpler, but >harder to detect. > >I have a routine -- unsigned long str8tolong(const char * str); -- which >expects str to be pointing at an 8 character hexadecimal value and returns >an unsigned long. I use it for parsing highly formatted input data. I have >several similar routines in one file - strfun.c - that was written, tested >and added to a library a long time ago. It turns out that str8tolong was >the only one that did NOT have a prototype in the header file. I have >apparently never yet used this particular function from that module. > >As a result, the compiler resorted to implicit parameter declaration, and >the return value was assumed (properly) to be of type integer. Since it was >then assigned to a long, it was sign-extended to a long, and my troubles >began. This bug was darn hard to find. > >I never noticed the implicit parameter declaration warning in the dozens of >meaningless warnings I get on every compile. Is there any way to promote a >particular warning to an actual error? Or is there any way to get a >particular type of warning to really stand out at compile time? This is a >nasty one, and should get more attention. > >Thanks, > >Paul Johnson > > > -----Original Message----- > > From: Erich Styger [mailto:] > > Sent: Wednesday, March 26, 2003 7:19 AM > > To: > > Subject: RE: [68HC12] Metrowerks Disassembly Obfuscation - Help! > > > > > > Hello Paul, > > what you see is called 'common code': the compiler folds togehter > > pieces of > > code > > at to the end of the function. > > You may use the option -Onf to switch this optimization off. > > > > But some questions: > > how did you generate the listing file? With the decoder (decoding > > the object > > file) > > or decoding the .abs file? > > I ask because the output looks like generated from the .abs file (say > > function starts > > at 0000243, but the presence of relocation/fixup information) > > 0000027C 07FF BSR skipWhitespace ;abs = 027D > > says that it is an object file? > > > > What you see with the 0x07FF code pattern is the BSR instruction with the > > offset -1 plus > > a relocation/fixup which has to be resolved by the linker. > > So if the listing below is from the .abs file, this is potentially a bug. > > In case the linker cannot resolve the BSR call, the linker will issue an > > error. Did you > > see this? > > > > Hope this help, > > Erich > > > > > -----Original Message----- > > > From: Paul Johnson [mailto:] > > > Sent: Mittwoch, 26. Marz 2003 01:44 > > > To: > > > Subject: [68HC12] Metrowerks Disassembly Obfuscation - Help! > > > > > > > > > Hi Metrowerks gurus, > > > > > > I've disassembled a module in my program where I think there may be a > > > problem. I have include the relevant section below, which has a > > > construction that I cannot understand. Can someone explain it > > to me? The > > > problems are described inline, starting with ***. > > > > > > 143: char * parseLong(char * str,long * data) > > > parseLong: > > > 00000243 3B PSHD > > > 145: str = skipWhitespace(str); > > > 00000244 EC84 LDD 4,SP > > > 00000246 0734 BSR *+54 ;abs = 027C > > > > > > *** I have to assume that there is a call of skipWhitespace at 027C, but > > > wait until you see what's actually there (below) > > > > > > 146: if ((*str == ',') || !(*str)) { > > > 00000248 2704 BEQ *+6 ;abs = 024E > > > 0000024A E600 LDAB 0,X > > > 0000024C 2610 BNE *+18 ;abs = 025E > > > 147: *data = 0; > > > 0000024E EE80 LDX 0,SP > > > 00000250 C7 CLRB > > > 00000251 87 CLRA > > > 00000252 6C02 STD 2,X > > > 00000254 6C00 STD 0,X > > > 148: if (*str) str++; > > > 00000256 EE84 LDX 4,SP > > > 00000258 E600 LDAB 0,X > > > 0000025A 271C BEQ *+30 ;abs = 0278 > > > 0000025C 2017 BRA *+25 ;abs = 0275 > > > 151: *data = str8tolong(str); > > > 0000025E B754 TFR X,D > > > 00000260 160000 JSR str8tolong > > > 00000263 160000 JSR ILSEXT > > > 00000266 ED80 LDY 0,SP > > > 00000268 6C42 STD 2,Y > > > 0000026A 6E40 STX 0,Y > > > 152: str+=8; > > > 0000026C EC84 LDD 4,SP > > > 0000026E C30008 ADDD #8 > > > 153: str = skipWhitespace(str); > > > 00000271 0709 BSR *+11 ;abs = 027C > > > 154: if (*str == ',') str++; > > > 00000273 2603 BNE *+5 ;abs = 0278 > > > 00000275 08 INX > > > 00000276 6E84 STX 4,SP > > > 155: return(str); > > > 00000278 EC84 LDD 4,SP > > > 157: } > > > 0000027A 30 PULX > > > 0000027B 3D RTS > > > > > > *** Here's the apparent call to skipWhitespace (which is at > > 0135), but the > > > disassembler says it's going to branch to 027d, which would > > start with the > > > opcode FF and be out of phase with everything else. > > > > > > 0000027C 07FF BSR skipWhitespace ;abs = 027D > > > 0000027E 6C86 STD 6,SP > > > 00000280 B745 TFR D,X > > > 00000282 E600 LDAB 0,X > > > 00000284 C12C CMPB #44 > > > 00000286 3D RTS > > > > > > Can someone explain this to a tired, old programmer? > > > > > > Thanks, > > > > > > Paul Johnson > > > > > > > > > > > > -------------------- > > > >http://www.motorola.com/mcu > > > > > > > > > ">http://docs.yahoo.com/info/terms/" target="_blank" rel="nofollow">http://docs.yahoo.com/info/terms/>http://docs.yahoo.com/info/terms/ > > > > > > > > > > > > > > -------------------- > > >http://www.motorola.com/mcu > > > > > > ">http://docs.yahoo.com/info/terms/" target="_blank" rel="nofollow">http://docs.yahoo.com/info/terms/>http://docs.yahoo.com/info/terms/ > > > > ><http://www.gotomypc.com/u/tr/yh/cpm/grp/300_06F/g22lp?Target=mm/g22lp.tmpl>1938aca.jpg" target="_blank" rel="nofollow">http://rd.yahoo.com/M$6920.2960106.4328965.2848452/D=egroupweb/S06554205:HM/A08991/R=2/id=noscript/*http://www.gotomypc.com/u/tr/yh/cpm/grp/300_06F/g22lp?Target=mm/g22lp.tmpl>1938aca.jpg > >1938b24.jpg > >-------------------- >>http://www.motorola.com/mcu >">http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service. ************************************************************************* Steve Russell mailto: Senior Software Design Engineer http://www.nohau.com Nohau Corporation phone: (408)866-1820 51 East Campbell Avenue fax: (408)378-7869 Campbell, CA 95008 ************************************************************************* |
Reply by ●March 27, 20032003-03-27
Hi list,
I agree in principle, having been burned more than I ought to be by ignoring
warnings. However, I don't know what to do about the following CodeWorrier
warning: Warning : C12056 : SP debug info incorrect because of optimization or inline assembler. Anyhow, there's no inline assembler and the code seems to work just fine so I presume it's a result of some ooptimization or other. I get rid of it with a #pragma, but it's still a little worrying. Can anyone explain what this message is really trying to tell me?? And if I ought to be concerned about it at all? And even how I might get rid of it by modifying the source code? thanks, Pat Steve Russell wrote: > Hi Paul, > > Let me add my voice to the chorus and explain why I compile with the > highest warning level available, and keep the warnings to zero. > > As others have pointed out, it is easy to prevent a warning from being > printed, either by using a #pragma or by adding a cast or redundant assignment. > > So suppressing the ones that you have determined you are not interested in > one by one is pretty easy. > > The advantage is that when you add new code with that produces a warning, > you get told about it by the compiler, and you can easily fix it, because > the compiler is pretty good about pointing to exactly where the problem is. > > Sometimes the problem is obvious and a quick edit will fix it. > > Sometimes the problem is that you really don't understand some C feature, > and you have to study the manuals. In this case you learn something. > > Sometimes its just the compiler being picky, and you can make it shut up > with a quick edit. > > On the average all of these take much less time than loading the program > and debugging it, as you just reported. > > Keeping the reports of warnings to zero as a matter of policy, saves your > time (and frustration)! > > Steve |
|
Reply by ●March 27, 20032003-03-27
I get that warning, too. I hate ignoring warnings, but I also don't
have a clue what it means, or how to get rid of it. I have so far just supposed that it means that the debugger will be a little weak. Most of my code is assembly. I do have some in-line assembly statements in my C code. I'd love to hear an explanation. The debugger seems to work fine. Oddly, I can't determine when I will get the warning message. Doing a full build doesn't trigger it. It just pops up every now and then. "CodeWorrier," good one. Bob White ----- Original Message ----- From: "Pat Fitzpatrick" <> To: <> Sent: Thursday, March 27, 2003 3:30 PM Subject: Re: [68HC12] Metrowerks Disassembly Obfuscation - Help! Hi list, I agree in principle, having been burned more than I ought to be by ignoring warnings. However, I don't know what to do about the following CodeWorrier warning: Warning : C12056 : SP debug info incorrect because of optimization or inline assembler. Anyhow, there's no inline assembler and the code seems to work just fine so I presume it's a result of some ooptimization or other. I get rid of it with a #pragma, but it's still a little worrying. Can anyone explain what this message is really trying to tell me?? And if I ought to be concerned about it at all? And even how I might get rid of it by modifying the source code? thanks, Pat Steve Russell wrote: > Hi Paul, > > Let me add my voice to the chorus and explain why I compile with the > highest warning level available, and keep the warnings to zero. > > As others have pointed out, it is easy to prevent a warning from being > printed, either by using a #pragma or by adding a cast or redundant assignment. > > So suppressing the ones that you have determined you are not interested in > one by one is pretty easy. > > The advantage is that when you add new code with that produces a warning, > you get told about it by the compiler, and you can easily fix it, because > the compiler is pretty good about pointing to exactly where the problem is. > > Sometimes the problem is obvious and a quick edit will fix it. > > Sometimes the problem is that you really don't understand some C feature, > and you have to study the manuals. In this case you learn something. > > Sometimes its just the compiler being picky, and you can make it shut up > with a quick edit. > > On the average all of these take much less time than loading the program > and debugging it, as you just reported. > > Keeping the reports of warnings to zero as a matter of policy, saves your > time (and frustration)! > > Steve -------------------- ">http://docs.yahoo.com/info/terms/ |
|
Reply by ●March 28, 20032003-03-28
You get a description of the messages here: go to the preference panel, Messages, select the message you want to have the information about, and press F1/Help. They are also all listed in the PDF file located in CodeWarrior Manuals\pdf\Manual Compiler HC12.pdf Erich > -----Original Message----- > From: Bob White [mailto:] > Sent: Freitag, 28. Mz 2003 01:50 > To: > Subject: Re: [68HC12] Metrowerks Disassembly Obfuscation - Help! > I get that warning, too. I hate ignoring warnings, but I also > don't have a > clue what it means, or how to get rid of it. I have so far just supposed > that it means that the debugger will be a little weak. Most of my code is > assembly. I do have some in-line assembly statements in my C code. I'd > love to hear an explanation. The debugger seems to work fine. > > Oddly, I can't determine when I will get the warning message. > Doing a full > build doesn't trigger it. It just pops up every now and then. > > "CodeWorrier," good one. > > Bob White > > ----- Original Message ----- > From: "Pat Fitzpatrick" <> > To: <> > Sent: Thursday, March 27, 2003 3:30 PM > Subject: Re: [68HC12] Metrowerks Disassembly Obfuscation - Help! > Hi list, > I agree in principle, having been burned more than I ought to be > by ignoring > warnings. However, I don't know what to do about the following CodeWorrier > warning: > > Warning : C12056 : SP debug info incorrect because of > optimization or inline > assembler. > > Anyhow, there's no inline assembler and the code seems to work > just fine so > I presume it's a result of some ooptimization or other. I get rid > of it with > a #pragma, but it's still a little worrying. > > Can anyone explain what this message is really trying to tell > me?? And if I > ought to be concerned about it at all? And even how I might get > rid of it by > modifying the source code? > > thanks, > > Pat > Steve Russell wrote: > > > Hi Paul, > > > > Let me add my voice to the chorus and explain why I compile with the > > highest warning level available, and keep the warnings to zero. > > > > As others have pointed out, it is easy to prevent a warning from being > > printed, either by using a #pragma or by adding a cast or redundant > assignment. > > > > So suppressing the ones that you have determined you are not > interested in > > one by one is pretty easy. > > > > The advantage is that when you add new code with that produces > a warning, > > you get told about it by the compiler, and you can easily fix > it, because > > the compiler is pretty good about pointing to exactly where the problem > is. > > > > Sometimes the problem is obvious and a quick edit will fix it. > > > > Sometimes the problem is that you really don't understand some > C feature, > > and you have to study the manuals. In this case you learn something. > > > > Sometimes its just the compiler being picky, and you can make it shut up > > with a quick edit. > > > > On the average all of these take much less time than loading the program > > and debugging it, as you just reported. > > > > Keeping the reports of warnings to zero as a matter of policy, > saves your > > time (and frustration)! > > > > Steve > > -------------------- > > ">http://docs.yahoo.com/info/terms/ > > > -------------------- > > ">http://docs.yahoo.com/info/terms/ |