Next: Output Options, Previous: Language-affecting Options, Up: Invoking ick [Index]
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.
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.
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.
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).
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.
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.
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.
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.
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.
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).
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: Output Options, Previous: Language-affecting Options, Up: Invoking ick [Index]