Debug information for if(testbit == 0) test

sb
2008-02-16
2013-03-12
  • sb
    sb
    2008-02-16

    I have observed that then testing a bit using 'if(testbit == 0)' syntax instead of 'if(testbit)' syntax, the compiler does not generate acurate debug code for the test.

    When running the resulting code in my ICE kit, source lines actually compiled will be "active" and break, trace etc. functions can be activated or deactivated on the given source line.

    When the compiler optimizes the code due to a missing volatile declaration for instance, it is quite easy to see what source lines were actually compiled and which were removed/ignored during optimisation.

    When using the above mentioned 'if(testbit == 0)' or 'if(testbit == 1') notation, it seems as if the test was actually not compiled, but when looking into the assembly code it certainly were.

    It is not a big issue, but I believe the code sometimes might be more readable when using the mentioned syntax using '==', and I believe this is a bug in SDCC.

    Is it, or is this just a bad habit of mine ?

     
    • Maarten Brock
      Maarten Brock
      2008-02-18

      I do not understand what you want to say.
      First are you using it for an 8051?
      And can you provide an example which to you seems not to be compiled and what makes you conclude that? Is it only that you cannot set a breakpoint on the line?

      Maybe the line is combined with the next one? (e.g. 'if(testbit==1) testbit=0;')
      And remember that SDCC treats 'bit' variables as 'bool' as defined in the C standard which might need upcasts to 'int'.

       
    • sb
      sb
      2008-02-20

      This is about generated debug information.

      The statement is compiled, but no debug information is generated.
      To illustrate the issue, I have made a very simple dummy application given below.

      As you can observe from this, the two first tests generate debug information, but the two last tests does not generate debug code.

      When performing source level debugging using a third party tool depending on the debug information generated, it is vital to be able to "step" through all the compiled source lines and not just some.

      As noted before, this is not a big issue, but I still believe this is a "minor" bug in the compiler which you might want to fix.

      SOURCE CODE:
      void main()
      {
          if(Timeout){
              Timeout = 0;
          }
         
          if(!Timeout){
              Timeout = 1;
          }
         
          if(Timeout == 1){
              Timeout = 0;
          }
         
          if(Timeout == 0){
              Timeout = 1;
          }
      }

      GENERATER ASSAMBLY CODE:
      _main:
          C$test.c$17$1$1 ==.
      ;    test.c:17: if(Timeout)
          jnb    _Timeout,00102$
          C$test.c$19$2$2 ==.
      ;    test.c:19: Dummy = 0;
          clr    _Dummy
      00102$:
          C$test.c$22$1$1 ==.
      ;    test.c:22: if(!Timeout)
          jb    _Timeout,00104$
          C$test.c$24$2$3 ==.
      ;    test.c:24: Dummy = 0;
          clr    _Dummy
      00104$:
          jnb    _Timeout,00106$
          C$test.c$29$2$4 ==.
      ;    test.c:29: Dummy = 0;
          clr    _Dummy
      00106$:
          jb    _Timeout,00109$
          C$test.c$34$2$5 ==.
      ;    test.c:34: Dummy = 0;
          clr    _Dummy
      00109$:
          C$test.c$36$2$1 ==.
          XG$main$0$0 ==.
          ret

       
    • Maarten Brock
      Maarten Brock
      2008-02-21

      The generated asm was created for different source code. The shown C has no Dummy.

      My guess is that the debug info is removed by the peephole optimizer. You could try to compile again with --no-peep.

      HTH,
      Maarten

       
    • sb
      sb
      2008-02-23

      Sorry, cut and paste error..

      For reference, this is the source of the asm given before, together with the newly generater asm code now compiled with the --no-peep option enabled (sdcc "test.c" --debug --no-peep).

      No need to take this further however, it was just an "open" question whether this was thought of something to be fixed or not, and not something to prioritize anyway.

      The compiler seems well written, and I am impressed with the quick response (!)

      -------
      SOURCE
      -------
      void main()
      {
          if(Timeout)
          {
              Dummy = 0;
          }
         
          if(!Timeout)
          {
              Dummy = 0;
          }
         
          if(Timeout == 1)
          {
              Dummy = 0;
          }
         
          if(Timeout == 0)
          {
              Dummy = 0;
          }
      }

      -------
      ASM
      -------
      _main:
          C$test.c$17$1$1 ==.
      ;    test.c:17: if(Timeout)
          jb    _Timeout,00115$
          ljmp    00102$
      00115$:
          C$test.c$19$2$2 ==.
      ;    test.c:19: Dummy = 0;
          clr    _Dummy
      00102$:
          C$test.c$22$1$1 ==.
      ;    test.c:22: if(!Timeout)
          jnb    _Timeout,00116$
          ljmp    00104$
      00116$:
          C$test.c$24$2$3 ==.
      ;    test.c:24: Dummy = 0;
          clr    _Dummy
      00104$:
          jb    _Timeout,00117$
          ljmp    00106$
      00117$:
          C$test.c$29$2$4 ==.
      ;    test.c:29: Dummy = 0;
          clr    _Dummy
      00106$:
          jnb    _Timeout,00118$
          ljmp    00109$
      00118$:
          C$test.c$34$2$5 ==.
      ;    test.c:34: Dummy = 0;
          clr    _Dummy
      00109$:
          C$test.c$36$2$1 ==.
          XG$main$0$0 ==.
          ret