Bug #9
Compiler is broken
| Status: | Closed | Start date: | 04/14/2010 | |
|---|---|---|---|---|
| Priority: | High | Due date: | ||
| Assignee: |  Michael Fröhlich |
% Done: | 100% |
|
| Category: | Compiler | Spent time: | 1.00 hour | |
| Target version: | 0.9 | Estimated time: | 0.00 hour | |
| Difficulty: |
Description
The compiler seems to be broken currently.
Callstack is:
Unhandled Exception: System.NotSupportedException: Operation is not supported.
at Mosa.Platforms.x86.CILTransformationStage.Mosa.Runtime.CompilerFramework.CIL.ICILVisitor.Branch (Mosa.Runtime.CompilerFramework.Context ctx) [0x00000] in <filename unknown>:0
at Mosa.Runtime.CompilerFramework.CIL.BranchInstruction.Visit (ICILVisitor visitor, Mosa.Runtime.CompilerFramework.Context context) [0x00000] in <filename unknown>:0
at Mosa.Runtime.CompilerFramework.CIL.BaseInstruction.Visit (IVisitor visitor, Mosa.Runtime.CompilerFramework.Context context) [0x00000] in <filename unknown>:0
at Mosa.Runtime.CompilerFramework.Context.Visit (IVisitor visitor) [0x00000] in <filename unknown>:0
at Mosa.Runtime.CompilerFramework.CodeTransformationStage.Run () [0x00000] in <filename unknown>:0
at Mosa.Runtime.CompilerFramework.MethodCompilerBase.<Compile>m__4 (IMethodCompilerStage stage) [0x00000] in <filename unknown>:0
at Mosa.Runtime.CompilerFramework.CompilerPipeline.Execute[IMethodCompilerStage] (System.Action`1 action) [0x00000] in <filename unknown>:0
at Mosa.Runtime.CompilerFramework.MethodCompilerBase.Compile () [0x00000] in <filename unknown>:0
at Mosa.Tools.Compiler.LinkTimeCodeGeneration.LinkTimeCodeGenerator.Compile (Mosa.Runtime.CompilerFramework.AssemblyCompiler compiler, System.String methodName, Mosa.Runtime.CompilerFramework.InstructionSet instructionSet) [0x00000] in <filename unknown>:0
at Mosa.Tools.Compiler.x86.InterruptBuilderStage.CreateISRMethods () [0x00000] in <filename unknown>:0
at Mosa.Tools.Compiler.x86.InterruptBuilderStage.Run () [0x00000] in <filename unknown>:0
at Mosa.Runtime.CompilerFramework.AssemblyCompiler.<Compile>m__0 (IAssemblyCompilerStage stage) [0x00000] in <filename unknown>:0
at Mosa.Runtime.CompilerFramework.CompilerPipeline.Execute[IAssemblyCompilerStage] (System.Action`1 action) [0x00000] in <filename unknown>:0
at Mosa.Runtime.CompilerFramework.AssemblyCompiler.Compile () [0x00000] in <filename unknown>:0
at Mosa.Tools.Compiler.AotCompiler.Run () [0x00000] in <filename unknown>:0
at Mosa.Tools.Compiler.Compiler.Compile () [0x00000] in <filename unknown>:0
at Mosa.Tools.Compiler.Compiler.Run (System.String[] args) [0x00000] in <filename unknown>:0
at Mosa.Tools.Compiler.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0
History
Updated by Phil Garcia about 2 years ago
Bug seems to be triggered by the code stream generated by the InterruptBuilderStage.
Updated by Phil Garcia about 2 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
- Estimated time set to 0.00
The fix is to include the CILTransformationStage stage in the LinkerMethodCompiler.
The bug has been fixed in my repository and will be incorporated in main repository at the next merge.
Updated by Michael Fröhlich about 2 years ago
Phil,
it was my intent to remove CILTransformationStage. Please rewrite the InterruptBuilderStage to only use instructions from x86 (if it is past the IRTransformationStage) or IR if it is before it.
Mike
Updated by Simon Wollwage about 2 years ago
- Status changed from Resolved to In Progress
I'll leave this Issue open until compilation works again. Any objections?
Updated by Phil Garcia about 2 years ago
InterruptBuilderStage does not emit any CIL instructions. The real culprit is the BasicBlockBuilderStage which emits a CIL Branch instruction when creating the prologue block. What should it emit instead?
Updated by Phil Garcia about 2 years ago
Michael Fröhlich wrote:
Phil,
it was my intent to remove CILTransformationStage. Please rewrite the InterruptBuilderStage to only use instructions from x86 (if it is past the IRTransformationStage) or IR if it is before it.
Mike
Which stage us being removed: X86.CILTransformationStage or IR.CILTransformationStage?
Updated by Simon Wollwage about 2 years ago
x86.CILTransformationStage is removed, so that the backends only have to operate on IR
Updated by Phil Garcia about 2 years ago
Simon Wollwage wrote:
x86.CILTransformationStage is removed, so that the backends only have to operate on IR
The fix added IR.CILTransformationStage only.
So can close this ticket?
Updated by Michael Fröhlich about 2 years ago
I looked at the ISR stage. It only uses x86 instructions - can we use a subset of the compiler pipeline (x86 stages only?) to compile this? It seems to me that it doesn't need any of the earlier features.
Second I wanted to ask if we can rewrite this using the intrinsics in x86 Native? I'm worried that stages like this one open a can of worms...
Mike
Updated by Michael Fröhlich about 2 years ago
- Status changed from In Progress to Closed
Just commited all changes to my public repository. This bug is fixed along with several others. My repository boots again.
Updated by Phil Garcia about 2 years ago
- Status changed from Closed to In Progress
Michael Fröhlich wrote:
I looked at the ISR stage. It only uses x86 instructions - can we use a subset of the compiler pipeline (x86 stages only?) to compile this? It seems to me that it doesn't need any of the earlier features.
Yes, we only need to use a subset of pipelines (if any) for this.
Second I wanted to ask if we can rewrite this using the intrinsics in x86 Native? I'm worried that stages like this one open a can of worms...
When an interrupt is generated, the CPU will push the registers, return address, and 1-byte error code (depending on the type of interrupt) onto the stack. The code in the InterruptBuilderStage takes this information and sets up the stack to match the calling conversion of the managed interrupt handler method in the kernel and then calls it. And upon return from the managed interrupt handler, it properly unwinds the stack and exits the interrupt.
To move this same logic into manage code would require the same steps; however, the compiler will get in the way by generating native method stack frames and temporary variables. In addition, this introduces another complexity in getting the pointers to the interrupt handler to setup the interrupt table.
I’m all for moving as much of this platform specific stuff into managed kernel. However, I don’t see a good alternative method right now but I’m open to ideas.
Updated by Phil Garcia about 2 years ago
Michael Fröhlich wrote:
Just commited all changes to my public repository. This bug is fixed along with several others. My repository boots again.
Great! I'll merge the code into the main repo tonight. Please pull from main repo tomorrow so we sync up.
Updated by Simon Wollwage about 2 years ago
- Status changed from In Progress to Resolved
Updated by Simon Wollwage about 2 years ago
- Status changed from Resolved to Closed