How to avoid the .d/.p file generation?

Lou Cyphre
  • Lou Cyphre

    Lou Cyphre - 2007-02-27

    I'm compiling for PIC16F636 (-mpic14) and I'm getting a .d/.p file on compilation -- i.e. compiling file code.c I have code.d and code.p generated.
    How can I avoid those debug(?) files?

    Note that the two files above aren't _always_ generated. With some sources both of them are retained, while sometimes they aren't, with different sources, or in dependency of compiler product (only .asm / gpasm).

    [SDCC 2.6.4 / 4651 / Win32]

    ~ Lou

    • kosmonaut_pirx

      kosmonaut_pirx - 2007-02-27

      in the way i know, .d -files are dependency files generated by the preprocessor. with a clever Makefile, there shouldn't be any problems with it, as a usual "make clean" will eliminate them.

      please post your complete sdcc calls for a compilation of an example file. the options given there can tell more.

      bye kosmo

    • Lou Cyphre

      Lou Cyphre - 2007-03-06

      This is *not* the case of dependency files.
      I narrowed the case reducing a source file so that it can be reproduced easily.
      Note: I found a cause that generates the .d/.p files, and I'm telling it at the end of this message (though I didn't find how to avoid it).

      Using the following:
      --- file: bar.c  --------------------------

      static char    fvalue( char x )
          return  x;

      void    main( void )

      ------ end of file ------------------------
      Note: yes, no one calls fvalue(), but this isn't the issue

      And compiling it with
        % sdcc -mpic14 -p16f628 bar.c
      You can obtain a file bar.d, so large that's not feasible to paste it here (over 24 KiB), where you see lines like these:
      ------------- begin of file ---------------
      newReg: Created register STK00.
      newReg: Created register STK01.
      newReg: Created register STK02.
      newReg: Created register STK03.
      newReg: Created register STK04.
      newReg: Created register STK05.
      [... omitted ...]
      Basic Block _entry : loop Depth = 0 noPath = 0 , lastinLoop = 0
      depth 1st num 1 : bbnum = 0 1st iCode = 1 , last iCode = 4
      visited 0 : hasFcall = 0

      defines bitVector :bitvector Size = 6 bSize = 1
      Bits on { (2) }
      [... omitted ...]
      ------ end of file ------------------------

      In addition to it there's a file bar.p, with "pcode dump", as it tells.

      If you modify the function fvalue() to have no calling parameter the .d/.p files *disappear* (or better, aren't generated anymore).
      With a source file growing to a few hundred lines, the .d file reaches easily many hundreds of KiB.

      ~ Lou

    • kosmonaut_pirx

      kosmonaut_pirx - 2007-03-06


      tryed your out-of-the-box-program with another configuration:

      sdcc-snapshot/bin/sdcc -mhc08 bar.c

      nothing bad happens.
      this leads me to the conclusion, that this is a pic-related issue. please read the manual for this

      there's something written about the .d-files, i've seen already. don't want ( and have) to look for the .p-files.

      bye kosmo

    • Lou Cyphre

      Lou Cyphre - 2007-03-09

      Those notes are in fact for the PIC16 port, where you can enable/disable the .d/.p files generation, while for the PIC14 port (-mpic14) it shows a "random" behavior, with no options on command line to enable/disable it.
      I'll file it as a bug, then.

      ~ Lou

      • Raphael Neider

        Raphael Neider - 2007-03-09

        OK, fixed in SDCC 2.6.4, r4672.

        .p files can now be obtained using the --debug flag, .d files were never meant to be produced by users and are now disabled (debug variable in ralloc.c enables .d file generation after having recompiled sdcc, if anyone cares...)

        Sorry for the late response, obviously my email monitor for this forum has vanished somehow---didn't get the info until you posted the bug report. Thanks for that!



Log in to post a comment.