Mail Archives: djgpp/2004/07/27/16:14:11
> From: sterten AT aol DOT com (Sterten)
> Newsgroups: comp.os.msdos.djgpp
> Date: 27 Jul 2004 08:14:13 GMT
>
> The output is rather ugly, because many instructions require more than line
> and because of the the ATT-assembly-code.
I don't see anything ugly about it. Perhaps I'm too used to it...
> BTW. why is it used ? Is it easier for the disassembler or for historical
> reasons or ?
Because Unix assemblers use the AT&T style, and GCC was ported from
Unix.
> why is it affected by small changes in the program ?
Because you effectively use a random value as an index into array.
Small changes in the program rearrange the array locations a bit, and
thus the random value becomes valid (i.e., non-negative and small
enough to not exceed the limits of the program's data segment). But
the program still works incorrectly (produces incorrect results), so
the bug is still there.
> 82:qser3.c **** c=C[r];r2=n+1-r;c2=n+1-c;
> 549 .loc 1 82 0
> 550 L82:
> GAS LISTING c:/djgpp/tmp/ccKJ0PeS.s page 16
>
>
> 551 0706 B8200B00 movl $_C, %eax
> 551 00
> 552 070b 8B4DC8 movl -56(%ebp), %ecx
> 553 070e 8B55C8 movl -56(%ebp), %edx
> 554 0711 29F9 subl %edi, %ecx
> 555 0713 8B1CB8 movl (%eax,%edi,4), %ebx
> 556 0716 41 incl %ecx
> 557 0717 29DA subl %ebx, %edx
> 83:qser3.c **** R[r]=0;R[r2]=0;R[c]=0;R[c2]=0;
> 84:qser3.c **** C[c]=0;C[c2]=0;C[r2]=0;//C[r]=0;
Line 84 is the one that crashes, and it sounds like c's value is bad,
probably because some prior code overwrote the contents of C[r], or
because the value of r is bad (e.g., negative).
So now you know what causes the bug, and you should be able to fix the
program. The logic should ensure that r never becomes negative, and
that no other index ever goes below zero.
- Raw text -