Next: , Previous: , Up: Invoking ick   [Index]


2.2 Debug Options

Sometimes things will go wrong with your program, or with the way ick was installed. There may even be unknown bugs in ick itself (if you find one of these, please report it). The following options are used to debug the whole system on various levels.

-d

If you think that something has gone wrong with the parser, or you want to see how your program is being parsed, you can give this option on the command line. All the debug output produced by the parser and lexical analyser will be output.

-g

This option allows debugging of the final executable at the C code level. Any C code generated will be left in place, and the -g option will be given to the C compiler that’s used to compile the code, so all the information needed for a C debugger to be used on the executable will be present there.

-h
-H
-hH

These options allow debugging of the optimiser, or produce output helpful for understanding how your program has been summarised. -h produces a summary of what optimiser rules were used, the initial expression and what it was optimised to; -H produces a more expanded view that shows each intermediate step of optimisation, and -hH shows the same output as -H, but written completely using C syntax (the other options output in a strange mix of INTERCAL and C).

-l

This option turns on generation of warnings (see Warnings). To make sure that they aren’t actually useful, or are only marginally useful, the warning generator is far too sensitive, and there is no way to decide which warnings are given and which ones aren’t; you either get all of them or none.

-p

This option causes the program to run immediately after being compiled, and profiles the resulting program to identify performance bottlenecks, etc. The usefulness of this depends on the resolution of the timers on the computer and operating system; DOS, in particular, is really bad with timer resolution. The output will be saved in a file called yuk.out when the program finishes running. It’s legal to turn on both the profiler and the interactive debugger at the same time, but if you do this the profiler will also identify bottlenecks in the person typing in commands to step through the program! The profiler will, in fact, identify all the timings that particular commands in the program take; so WRITE IN instructions will often show up as taking a long time due to their need to wait for input.

-w

This option causes the produced program to support the printflow option fully; when this option is not given, printflow will in most cases have partial or no support (except in multithreaded programs, where this option is redundant), because not all the code needed for it will be included in the program to save space.

-u

When you are getting problems with finding files – for instance, the compiler can’t find the skeleton file (see E999) or the system library (see E127) – this option will let you know, on standard error, where the compiler is looking for files. This may hopefully help you pin down where the file-finding problems are coming from, and also offers the option of simply placing copies of the files where the compiler is looking as a last resort.

-y

This is the main debugging option: it loads yuk, an interactive INTERCAL debugger with ability to step through the program, set breakpoints, view and modify variables, etc. See yuk.

-Y

This options causes the command line to be displayed for all calls to other programs that ick makes (mostly to gcc); it is therefore useful for debugging problems with the command lines used when using the external calls system (see External Calls).

-U

The internal error E778 (see E778) should never happen. However, there are all sorts of potential problems that may come up, and if part of the code detects something impossible, or more usually when the operating system detects things have got too insane and segfaults, normally this error will just be generated and that’s that. (I most often get this when I’ve been writing a new section of code and have made a mistake; hopefully, all or at least most of these errors are fixed before release, though.) If you want more information as to what’s going on, you can give the -U option, which will cause the compiler to raise an abort signal when an internal error happens. This can generally be caught by a debugger that’s being run on ick itself at the time; on many systems, it will also cause a core dump.


Next: , Previous: , Up: Invoking ick   [Index]