[WIP] Backport GC4 new dump feature to GC3

[ddeclerck]

Following #130 , attempt to backport the dump / symtab feature from GC4 to GC3.

Note that I kept the "old" text dump for backward compatibility.

"Mostly" works, but breaks 25 tests, mainly due to subtle divergences betwen the GC3 and GC4 branches. I could fix some. For others, I'm not sure about the right way to fix them. Here are a few of the problematic ones and my observations.

990: FUNCTION BYTE-LENGTH
1030: FUNCTION LENGTH

Generates invalid C: missing field variable. This is due to the fact that GC3 inlines calls to LENGTH on fields with a NATIONAL category while GC4 does not inline them, preventing the generation of the field in the C code. Note that LENGTH of fields with an ALPHANUMERIC category are also inlined but do not suffer for this problem, possibly because of the field initialization code (I suppose because initialize_uniform_char is defined for ALPHANUMERIC but not NATIONAL).

679: LOCAL-STORAGE (3)

Generates invalid C: storing the address of a non-static index variable into a static variable. This is due to a fix (bug 794) in GC3, which allowed the index type to be either CB_INT_INDEX or CB_STATIC_INT_INDEX (see parser.y:occurs_index). In GC4, it is always CB_STATIC_INT_INDEX thus we never run into problems.

1163: System routine C$NARG

Generates invalid C : storing the address of a non-static variable into a static variable. This is due to a different handling of procedure parameters (USING...) between GC3 and GC4. In GC3, the C function generated for a procedure with parameters has the field passed as arguments, while in GC4 these parameters are stored in (static) field in the local storage.

808: stack and dump feature
809: dump feature with NULL address

Divergence in the ouput, probably because the old and new dumps don't do exactly the same thing. I yet have to investigate more into this.

[GitMensch]

And just to check: would this already solve the initial needs which were the reasons for #130?

Note; we should take this new code live once it works, as it:

• creates smaller code and is faster on the C compiler side (by numbers, if the programs have a huge number of copybooks, ähm, variables)
• handles the SIGSEGV during dump issue, which is important for the call_with_exception stuff (and when being called for example from JAVA)

[ddeclerck]

Don't know where I'm going with this, but in essence, the main problem comes from new features in GC3 that were not included yet in GC4 (and not the opposite). For instance, the changes introduced in GC3 by commits 4653 and 4886 actually break the dump feature if we port them to GC4. So that would probably mean it would be best to first forward port from GC3 to GC4 any new commit that might break the dump feature and make the appropriate fixes in GC4, before backporting the whole dump feature to GC3...