search

minexew / templeos-loader

User-space loader for TempleOS
4 stars 6 forks source link

Changing COMPILER env var can leave compiler in a broken state due to incorrect header files. #19

Open tos11 opened 4 years ago

tos11 commented 4 years ago

This issue will only effect people trying to modify the TOS compiler API.

Setting the COMPILER env variable only effects the AOT compiled BIN file loaded in HolyCRT/InitRuntime.HC, but does not currently change the header files loaded in MiniSystem/AdamInit.HC. If changes are made to the compiler's API which changes CompilerA.HH or CompilerB.HH, then the new header files need to be loaded instead of those included with the initial default MiniSystem.

Maybe instead of having the COMPILER env variable point to a BIN file, it should point to a directory in which we expect to find Compiler.BIN, CompilerA.HH, and CompilerB.HH as well as any other files the compiler requires (ex: OpCodes.DD)?

minexew commented 4 years ago

The env variable was never intended to facilitate loading incompatible versions of the compiler. Since the compiler ABI is also used by kernel itself, if you change one you will generally need to recompile both, and then you would copy all the updated headers into MiniSystem.

Redirection of headers would require special-casing the hardcoded file names somewhere in FileOpen (because they are being included by absolute paths everywhere in TempleOS)

For Opcodes.DD, the situation is simpler, because compiler simply loads it from CurDir when it starts.

The situation is yet different in static builds (which I find superior for almost all purposes), since we link the compiler directly into the templeos Linux executable.

These are my views. Now we can argue! :)

tos11 commented 4 years ago

I understand the confusion. I'm not modifying anything which the Kernel directly interfaces with (though I am modifying things those functions they call). I'm changing some of the internal guts and adding some functions I want to call from the command line. For example I have a Cmp2 function like Cmp, but outputs more metadata about the compilation I'm interested in studying. This Cmp2 function is never called by the Kernel, but right now as things are implemented the system is unaware of Cmp2 because it includes the compiler headers from the MiniSystem and not those from the actual compiler which is loaded (which include my Cmp2 function).

Right now I just copy my new compiler headers over the MiniSystem version and that is a fine workaround. This is mostly just an FYI and not likely a problem most users will ever encounter. I just wanted to point it out in case you thought it was worth changing.

tos11 commented 4 years ago

I'm trying to make a serious effort to replace my currently QEMU driven build process with this. I've had chicken and egg problems with the Adam and the Kernel too. The best solution seems to be to boot up with plain Temple OS drive C, (except perhaps change some of the Kernel and Compiler headers so new types and function prototypes are there for the build process). Then I'm putting the other files I want to modify somewhere on drive D. After it boots up I copy all the new files from D over top of those on C before running DoDistro. I had to do this because my Adam contains changes which depend on Kernel functions which do not exist in the Virtual Kernel (so my Adam crashes the boot process). I also make sure to create all the directories I'm going to write to ahead of time before launching and that all files are decompressed so I don't accidentally create .HC and .HC.Z pairs.