Earlier, I wrote:
>
> I think I have tracked down the Windows mcode
> stack allocation bug, with a fix better than the
> double-the-stack-alignment-constant hack I mentioned
> earlier; I'll post a patch in a day or so once I've
> run it against some non-trivial VHDL source code.
>
As it turns out, that 'bug' was a figment of my imagination,
I counted wrong when looking at the frame prologue code.
But my change sort-of-worked, by accidentally padding the
stack frame in Emit_Prologue by 8 bytes.
With this 8 byte padding, the tristate test runs OK, as
well as my actual testbench, but the DLX example code fails.
Changing Stack_Boundary to 16 runs all of the above.
--------
Again, I don't think either change addresses the actual problem,
but is just padding things enough to prevent the memory exception
caused by the actual problem(s).
FWIW, change fragments for the stack debug edits follow below.
Brian
stack crash debugging patches to 0.29.1
built on WinXP, GNAT GPL 2010
ortho/mcode/ortho_code-x86-flags_windows.ads
- Stack_Boundary : constant Unsigned_32 := 2 ** 3;
+ Stack_Boundary : constant Unsigned_32 := 2 ** 4;
ortho/mcode/ortho_code-x86-emits.adb
+ -- BMD add extra padding to stack frame before alignment
+ -- still crashes on win32 / align 8
+ Frame_Size := Frame_Size + 8;
+
-- Align.
Frame_Size := (Frame_Size + X86.Flags.Stack_Boundary - 1)
and not (X86.Flags.Stack_Boundary - 1);
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
