Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resetting the lines option to 0 still outputs #line directives #51

Closed
medranocalvo opened this issue Feb 11, 2015 · 4 comments
Closed
Assignees
Labels
Milestone

Comments

@medranocalvo
Copy link

For debugging, it is helpful turning the off the source line linking (::critcl::config lines 0), and instead look at the generated C file. See http://wiki.tcl.tk/13214.

When turning this option off, critcl still generates some of the#line pragmas, making the result unusable. The sources of #line pragmas are at least the following:

  • Templates including the pragmas:

    lib/critcl-class/class.h:64:#line 65 "class.h"
    lib/critcl-class/class.h:77:#line 78 "class.h"
    lib/critcl-class/class.h:101:#line 102 "class.h"
    lib/critcl-class/class.h:131:#line 131 "class.h"
    lib/critcl-class/class.h:145:#line 145 "class.h"
    lib/critcl-class/class.h:155:#line 155 "class.h"
    lib/critcl-class/class.h:162:#line 162 "class.h"
    lib/critcl-class/class.h:321:#line 320 "class.h"
    lib/critcl-iassoc/iassoc.h:16:#line 17 "iassoc.h"
    lib/critcl-iassoc/iassoc.h:28:#line 29 "iassoc.h"
    lib/critcl-iassoc/iassoc.h:38:#line 39 "iassoc.h"
    lib/critcl/critcl_c/pkginittk.c:2:# line 1 "MyInitTkStubs"
    lib/critcl/critcl_c/stubs.c:2:# line 1 "MyInitTclStubs"
    lib/critcl/critcl_c/stubs_e.c:2:# line 1 "MyInitTclStubs"
    
  • Code generated upon Initialize. This procedure is invoked when requiring the package, so the configuration option has not had a chance of been reset before it runs.

One option would be guarding the #line directives by #if SHOW_LINES, and defining it to whatever the user has configured when compiling. What do you think?

@andreas-kupries andreas-kupries self-assigned this Feb 11, 2015
@andreas-kupries andreas-kupries modified the milestone: 3.1.13 Feb 11, 2015
@andreas-kupries
Copy link
Owner

How does still having the #line directives break the debugging ?

  • For the templates in helper packages (like "class" and iassoc") it should be trivial to have them drop the directive from the output based on the state of 'config lines' (Have to check if this config can be queried outside of the critcl core).
  • You are correct that generated before setting the config will not capture the proper setting, like in Initialize (Have to check what that code is). It might be possible to remove the directives after the fact, just before compilation.
  • Not sure about the SHOW_LINES ... Have to check if that actually works, and also if using this would require changing the line numbers.

Will investigate.

@medranocalvo
Copy link
Author

All lines below the #line get mapped to the file indicated in the directive. For example, the following program:

package require critcl 3.1.12;

::critcl::tcl 8.6;
::critcl::config force 1;   # Recompile.
::critcl::config keepsrc 1; # Keep sources.
::critcl::config lines 0;   # Lines reference generated source.

::critcl::cproc ::twice {int i} int {
    return i * 2;
}

::critcl::load;

Has the following #line directives:

/* Generated by critcl on Thu Feb 12 08:07:32 CET 2015
 * source: /tmp/critclline.tcl
 * binary: /tmp/_cache/v3112_324a96ccbd71d1afcc6a66e991bec9c2_pic.o
 */

#include "tcl.h"

/* ---------------------------------------------------------------------- */

#define ns__twice2 "::twice"
static int c__twice2(int i)
{
return i * 2;
}

static int
tcl__twice2(ClientData cd, Tcl_Interp *interp, int oc, Tcl_Obj *CONST ov[])
{
  int _i;
  int rv;
  if (oc != 2) {
    Tcl_WrongNumArgs(interp, 1, ov, "i");
    return TCL_ERROR;
  }

  /* (int i) - - -- --- ----- -------- */
    {
#line 4700 "critcl.tcl"
    if (Tcl_GetIntFromObj(interp, ov[1], &_i) != TCL_OK) return TCL_ERROR; }

  /* Call - - -- --- ----- -------- */
  rv = c__twice2(_i);

#line 4794 "critcl.tcl"
    Tcl_SetObjResult(interp, Tcl_NewIntObj(rv));
    return TCL_OK;
}

/* ---------------------------------------------------------------------- */

# line 1 "MyInitTclStubs"

#if USE_TCL_STUBS
   const TclStubs *tclStubsPtr;
   const TclPlatStubs *tclPlatStubsPtr;
  const struct TclIntStubs *tclIntStubsPtr;
  const struct TclIntPlatStubs *tclIntPlatStubsPtr;

  static int
  MyInitTclStubs (Tcl_Interp *ip)
  {
    typedef struct {
      char *result;
      Tcl_FreeProc *freeProc;
      int errorLine;
      TclStubs *stubTable;
    } HeadOfInterp;

    HeadOfInterp *hoi = (HeadOfInterp*) ip;

    if (hoi->stubTable == NULL || hoi->stubTable->magic != TCL_STUB_MAGIC) {
      hoi->result = "This extension requires stubs-support.";
      hoi->freeProc = TCL_STATIC;
      return 0;
    }

    tclStubsPtr = hoi->stubTable;

    if (Tcl_PkgRequire(ip, "Tcl", "8.6", 0) == NULL) {
      tclStubsPtr = NULL;
      return 0;
    }

    if (tclStubsPtr->hooks != NULL) {
    tclPlatStubsPtr = tclStubsPtr->hooks->tclPlatStubs;
    tclIntStubsPtr = tclStubsPtr->hooks->tclIntStubs;
    tclIntPlatStubsPtr = tclStubsPtr->hooks->tclIntPlatStubs;
    }

    return 1;
  }
#endif

#ifdef __cplusplus
extern "C" {
#endif

DLLEXPORT int
Critclline_Init(Tcl_Interp *ip)
{
#if USE_TCL_STUBS
  if (!MyInitTclStubs(ip)) return TCL_ERROR;
#endif


  Tcl_CreateObjCommand(ip, ns__twice2, tcl__twice2, NULL, 0);
  return TCL_OK;
}
#ifdef __cplusplus
}
#endif

When debugging it with GDB, no source ever comes up for some parts, as "critcl.tcl" is not found. By the way: it would be best to have critcl output the full path to the file in the #line directive, both for critcl.tcl and for the tcl files, so that one does not need to configure the source path on the debugger.

Regarding the SHOW_LINES you can ignore it, it was intended as a simplest-thing-that-could-work suggestion.

Thank you very much for having a look at this.

Best regards,
Adrián Medraño Calvo.

@andreas-kupries
Copy link
Owner

Fixed with four commits. Unfortunately tagged as 'Issue 50', so github will have linked them there.
The relevant commits are

This looks to be done.

@medranocalvo
Copy link
Author

Wonderful! Thank you very much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants