debugger sometimes shows wrong register for integer value

[Franzki]

I was debugging a simple WIN32 console application, but the value that I directly assign to an integer did not show up right in the debugger.

In a function I declare an integer and assign a value to it:
 
int i;
i=0;

The debugger showed a value of 12 for integer i in register edi (i  {edi = 12}  int). The code does work well so it seems that the debugger shows the wrong register value for the integer. In this case the integer value appears to be stored in edx instead of edi.

I could not reproduce this writing some simple code.

[severach]

I can

Code: [Select]

if (1) {
  int i=5;
  printf("%d",i);
}

if (1) {
  int i=7;
  printf("%d",i);
}
It's a scoping problem. You might need to disable the optimizer to actually see it. Pointing at either variable will always return a particular one of the two values. The debugger window will show 'i' twice with both values but it's confusing. My solution was to stop making visually ambiguous scope variables.

[Franzki]

To be honest... I'm not an expert... and I'm not sure whether it's a real scoping problem. I'm only declaring the integer (i) once in the function.

This is the actual code in the function:

Code: [Select]

char * findveld (char *tbuffer, int num)
{
  int i;
  i=0;
  while(num>0)
  {
    while(tbuffer[i]!= 0)
      ++i;
    -- num;
    ++i;
    if (tbuffer[i]==LF)
    {
      num=0;
      --i;
    }
  }
  return(&tbuffer [i]);
}

[frankie]

It's not a scoping problem, but the normal behaviour.
The register variable 'i' is initialized when necessary, this means just before its use.
If you debug showing machine code you'll see that the variable is initialized just before 'tbuffer' is accessed.
If you want to debug it in HLL, disable the optimizations, the compiler will not use register variables anymore and 'i' will be initialized as expected.

[Franzki]

@Frankie:

Thank you for your help on this issue.
I allready found out that without optimations things seem to appear as I expect.

I have to admit that your explanation seems to be totally right (though somehow confusing to me).

If I add some extra code that references 'integer i' right after declaring it, the expected value shows up and remains visible during debugging;

Code: [Select]

int i;
i=0;
printf("%d",i);
Though this code doesn't work:

Code: [Select]

int i;
i=0;
++i;
--i;


[frankie]

As I told, the compiler, when optimizations are on, initialize the value just before its use!.
So in the first case initialization happen immediatly because the first source line use it in printf, in the second case you make two actions that will not change the value (increment than decrement the value doesn't change value befor its use).
This is due to the fact that PellesC has a very strong optimizer, that recognizes unconsistent code generation (why produce two instructions when the first use of that variable will keep the original value?)
This simply demonstrates that PellesC is very efficient
If you try:

Code: [Select]

i++;
printf ("this is %d\n", i);
i--;You'll see that increment/decrement are effectively generated.
As more prove if you define and initialize a variable that you never use you'll get a warning and the variable is not allocated at all.

Anyway, while everybody forget to mension, you have always to disable optimizations while producing debuggable executable (M$ make it by default in debug version).

So no bug at all, but a good compiler (I couldn't expect less by Pelle  ).