GHC API: Access to nativeCodeGen?
Peter A Jonsson
pj at ludd.ltu.se
Tue Jul 19 12:17:11 EDT 2005
> > I had perl 5.005_03 first in my path, that made the splitter not
> > work. Changing to a newer version made it work. Maybe a test could be
> > added to configure to avoid too old versions of perl?
> I'll be happy to - but I don't know exactly what version of Perl we
> require. Any clues? What went wrong with the splitter?
Sorry for the bad description of the error. I'll try again: The
problem I had was a failed build and a silent failure of the
splitter. No error message or similar, just a return. Poking around
with it and running "perl splitter <args..>" manually gave a core dump
It didn't complain about parse errors or similar so my guess is that
the code in itself is 5.005_03-compatible, the splitter is just
triggering some bug in the perl machinery. I didn't think of writing
down any details at the moment since changing to 5.8.4 'fixed' my
Perl 5.6.0 seems to be released 2000-Mar-22, demanding that people who
build ghc have a perl that is no older than 5 years might be a
reasonable first step?
> > Needed a patch to build NCG. I tried to preserve as much of the
> > previous structure in order to avoid introducing bugs, but I wasn't
> > entirely successfull. I've attached the patch and would appreciate if
> > someone could glance over it looking for obvious errors.
> There are never any "obvious" errors in the NCG :-) I did glance over
> it, and it mostly looks like a straightforward change over to Cmm.
> Since your patch only touches code inside #ifdef sparc_TARGET_ARCH,
> which is currently broken anyway, I'm inclined to just merge it as-is.
That sounds good to me, a smaller diff would hopefully make my life
About the lack of sparc-support - is the problem that no active
developers have access to sparc-machines any longer or is there simply
no interest in sparc? If it is the former, contact me off list and
I'll try to help out.
> > With this patch a bunch of array tests with WAY=normal fails, all in
> > the same way:
> > Stack space overflow: current size 8388608 bytes.
> > Use `+RTS -Ksize' to increase it.
> Best guess is the code generated for a stack-check sequence is
> incorrect. Match up the assembly file (use -keep-s-file) with the Cmm
> (-ddump-opt-cmm) and see if you can spot the incorrect code. I can
> provide some gdb tips - let me know if you need more help.
Ahh, and here I was using -v5. This is much better.
The stack-check sequence you are referring to, is that in Cmm
represented by "if ((Sp + -12) < SpLim) goto <label>"? If that is the
case, I can't find any errors in the asm produced.
Any hints that would ease the burden of reading big chunks of
assembler would be much appreciated!
> Also, the codeGen tests are probably a better place to start
Ok, will look into this.
More information about the Glasgow-haskell-users