EmbeddedRelated.com
Forums
   Forums    More Forums    68hc12  

Metrowerks Disassembly Obfuscation - Help!

Started by Paul Johnson ●March 25, 2003
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


Reply by Erich Styger ●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 Paul Johnson ●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 Erich Styger ●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 Mike Burgess ●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 Karl Lunt ●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 Steve Russell ●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 Pat Fitzpatrick ●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 Bob White ●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 Erich Styger ●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/



You might also like... (promoted content)
Check out Memfault's New Sandbox!
Check out Memfault's New Sandbox!
Check out Memfault's New Sandbox!