Re: [q-lang-devel] Debugging AMD64

[Albert G. <Dr....@t-...>]

Thomas Pasch wrote:
> (moved here from the user list because this is development stuff)

Yes, good idea.

> First of all, I couldn't disable building the octave extension with
> --without-octave. Is this a bug with autoconf/automake?

IIRC, there's no --without-octave, because there are no library 
dependencies for this module. It just drives the octave program through 
a bidirectional pipe. So it should compile even if octave is not 
installed at all.

> Second, I wonder if it is possible to build q without (1) gmp and
> (2) without clib.

(1) No. (2) Yes, in principle, but I'm afraid you'll have to fiddle with 
the corresponding Makefile.am. (Also, you'll have to comment the 
"include clib"-line in prelude.q, otherwise the interpreter will 
complain about a missing clib.q when started.) If you take this route, 
you could as well try to just disable the building of *all* modules. I 
guess that it would be enough to just remove the "modules" entry in the 
SUBDIRS macro in the global Makefile.am.

> Last not least I begone to look at q.c:resolve():around 1674 (where
> the module load error is reported). Using the debugger was a
> little strange until I realized that the symbol go an additional
> (magic) prefix __qq__. (Is there an easy way to get rid of it?)

You could try to just make mangle.h an empty file. (IIRC, this might 
cause incorrect resolution of some shared lib entry points due to naming 
conflicts, at least on some systems.) Better get used to the name 
mangling, it's fairly straightforward. :)

> Most of the code is difficult to debug because it modifies untyped 
> memory with expression like:
> 
> char *fname = strsp+fnametb[modno];

That strsp variable belongs to the bytecode. The corresponding data is 
declared in qbase.h. In the interpreter, strsp ("string space") is just 
a dynamically allocated char vector holding all the static strings in 
the bytecode (string constants, symbol identifiers, module names etc.). 
The strings are just stored in sequence (each string is 
(char)0-terminated). In the remainder of the bytecode data (e.g., in the 
virtual machine ops) the string data is then referred to using just an 
index into the strsp array (the index is the index of the first 
character of the string). I guess that's more or less how almost any PL 
compiler or interpreter does this kind of thing. ;-)

Yes I know that the coding is a bit sloppy but, hey, this project was 
started when ANSI C was nothing but a spec. That's also why some 
portions of the code still look very much like K&R C. ;-)

> The first expression is part of the problem: strsp is set to 
> malloced memory but fnametb[modno] is always NULL.

If I'm not mistaken, fname[modno] should be an int, namely an index into 
strsp. And it shouldn't be zero, under no circumstances. If it is, then 
there's probably something going wrong in the bytecode compiler, qc.

> How and where are fnametb and symtb calculated?

Those are calculated while the bytecode compiler parses the source, in 
qc.y and qclex.l. IIRC, actually qc uses its own private copy of 
fnametb, _fnametb. Just grep for those symbols in src. The source files 
with a qc in front belong to the compiler, so this is where to look. 
Turning on DEBUG in qc (see below) should also help to track down this bug.

> Are the any routines that could help to "dump" this
> parts?

Compile everything with the DEBUG symbol defined. The bytecode compiler 
will then spit out most of the bytecode it generates in a (more or less) 
readable format on stdout. (Search for #ifdef DEBUG in src to find out 
exactly what information is printed.)

HTH,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikwissenschaft.uni-mainz.de/~ag