SDCC Listing file - C Code line numbers

Help
Serge Malo
2008-05-08
2013-03-12
  • Serge Malo

    Serge Malo - 2008-05-08

    Hi all,

    I am creating a C-Code debugger on top SDCC. I am trying do to step-by-step execution of the C code.
    My debugger is parsing the listing file to know which instruction are mapped to the C statements lines of the source code.
    I am wondering if this the best way to do it, because I have a strange result in the listing file of a simple code example.
    Can somebody tell me if the listing file is incorrect, or if I'm on the wrong path?
    Thanks to all!
    I'm using SDCC 2.8.0 under Windows XP 32-bit.

    Here is the example:
    sfr     at 0xFA P1PINCFG;
    sbit    at 0x94 P1_4;
    void main()
    {
        unsigned long int l_uiCounter = 0;
        P1PINCFG    = 0x00;
        P1_4        = 0;
        l_uiCounter = 0;
        while(1)
        {
            if (l_uiCounter == 0x00040000)
            {
                if (P1_4 == 0)
                {
                    P1_4 = 1;
                }
                else
                {
                    P1_4 = 0;
                }
                l_uiCounter = 0;
            }
            l_uiCounter++;
        }
    }

    In the listing file, I wonder why we see "rst_problem_example.c:20", where we do the "if (P1_4 == 0)".
    This looks like a bug to me, I think we should see "rst_problem_example.c:12"
    Here's part of the listing:
                        000A    152     C$rst_problem_example.c$10$2$2 ==.
                                153 ;    rst_problem_example.c:10: if (l_uiCounter == 0x00040000)
       000A BA 00 1A            154     cjne    r2,#0x00,00105$
       000D BB 00 17            155     cjne    r3,#0x00,00105$
       0010 BC 04 14            156     cjne    r4,#0x04,00105$
       0013 BD 00 11            157     cjne    r5,#0x00,00105$
                        0016    158     C$rst_problem_example.c$20$3$3 ==.
                                159 ;    rst_problem_example.c:20: l_uiCounter = 0;   /// LINE 20 ??????
       0016 20 94 04            160     jb    _P1_4,00102$
                        0019    161     C$rst_problem_example.c$14$4$4 ==.
                                162 ;    rst_problem_example.c:14: P1_4 = 1;
       0019 D2 94               163     setb    _P1_4
       001B 80 02               164     sjmp    00103$

     
    • Maarten Brock

      Maarten Brock - 2008-05-09

      That piece of C is located at line 20, so far so good. But why is this line of comment moved before those other instructions you wonder? Well that is the peephole optimizer at work. It cannot keep the comments in the exact right place and therefor moves them in front.

       
    • Serge Malo

      Serge Malo - 2008-05-12

      Hi again, thanks for the answer!

      Maybe I misinterpreted the listing file.
      I thought that the comment indicating a C line meant that this C line corresponds to the next line of assembly.
      Here is a longer extract of the listing file:

                                  153 ;    rst_problem_example.c:10: if (l_uiCounter == 0x00040000)
         000A BA 00 1A            154     cjne    r2,#0x00,00105$
         000D BB 00 17            155     cjne    r3,#0x00,00105$
         0010 BC 04 14            156     cjne    r4,#0x04,00105$
         0013 BD 00 11            157     cjne    r5,#0x00,00105$
                          0016    158     C$rst_problem_example.c$20$3$3 ==.
                                  159 ;    rst_problem_example.c:20: l_uiCounter = 0;
         0016 20 94 04            160     jb    _P1_4,00102$
                          0019    161     C$rst_problem_example.c$14$4$4 ==.
                                  162 ;    rst_problem_example.c:14: P1_4 = 1;
         0019 D2 94               163     setb    _P1_4
         001B 80 02               164     sjmp    00103$
         001D                     165 00102$:
                          001D    166     C$rst_problem_example.c$18$4$5 ==.
                                  167 ;    rst_problem_example.c:18: P1_4 = 0;
         001D C2 94               168     clr    _P1_4
         001F                     169 00103$:
                          001F    170     C$rst_problem_example.c$20$3$3 ==.
                                  171 ;    rst_problem_example.c:20: l_uiCounter = 0;
         001F 7A 00               172     mov    r2,#0x00
         0021 7B 00               173     mov    r3,#0x00
         0023 7C 00               174     mov    r4,#0x00
         0025 7D 00               175     mov    r5,#0x00

      The comment “C$rst_problem_example.c$20” is written twice. Is this normal?
      I think only the second comment is correct, and the first one should be “rst_problem_example.c:12: if (P1_4 == 0)".
      But as you say, this might be related to the peephole optimization which prevents the compiler to write the correct line.

      I have found another way to match the C lines and the assembly code: I parse the .cdb file instead of the listing file. In the .cdb file, there is no C line associated with the address 0x0016.
      Do you think we should flag something as “wrong” here, or this is a completely normal behavior of the compiler?

       
      • Maarten Brock

        Maarten Brock - 2008-05-13

        Hmm, lines 158/159 and 170/171 do look a little strange. And if there is also nothing for address 0x0016 in the cdb file, you might just have found a bug. Can you file a bug report with the source code attached (preferrably as small as possible)? And don't forget to mention the compiler version and the command line options used.

        Maarten

         
    • Serge Malo

      Serge Malo - 2008-05-13

      Ok, Thanks for your help!
      I'll try to reduce the source code as much as possible.

       

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks