On 1/04/11 9:22 PM David G. Koontz wrote:
> So somewhere between revision 93 and revision 108 a problem crept in.
>
> This all with the gnat/gcc 4.3 from MacAda.
>
> Next will be ghdl-0.27 (revision 101). I'm guessing it will go.
ghdl-0.27 is actually revision 103 the above is a typo.
I stopped and audited that the changes from ghdl.diff were in revision 108.
There were two variances the target declaration in
translate/ghdlddrv/Makefile which I had patched by hand in 108 and instead
of using ortho/mcode/ortho_code-x86-flags.ads -flags_macosx.ads was used
instead (and that's okay).
I audited the ghdl.diff changes in revision 103 and found the same two
differences these are okay.
I took the precaution of 'setenv CC gcc' before building and encountered one
error where object code generation from
ortho/mcode/ortho_code-x86-abi.adb failed because it couldn't find
ortho_code-x86-flags.ads. I took the expedient of copying it from
ortho_code-x86-flags_macosx.ads and changing the package declaration it
contained dropping _Macosx from Ortho_Code.Flags_Macosx
I think there was something fixing this showing up in
translate/ghdldrv/Makefile in revision 108.
This was with translate/ghdldrv/Makefile target=x86-darwin (in the Makefile
and as a command line declaration).
It built ln -s ghdl_mcode ghdl. make target=x86-darwin install.mcode to
build the libraries.
hello world ran. The DES chip model ran without error assertions. Checking
it with gtkwave and checking the output .ghw file date shows the simulation
was correct.
Revision 103 ghdl-0.27 worked under Mac OS X with the copied and patched
ortho_code-x86-flags.ads file.
The failure of revision 108 lies somewhere between revision 103 and revision
108. Three of the files mentioned in ghdl.diff
translate/ghdldrv/Makefile
translate/grt/grt-processes.adb
ortho/mcode/ortho_code-x86-emits.adb
were changed in revision 106 (and not up through 108). The Mac OS X failure
was either caused by one of those or something in one of revisions
104105106107 or 108 in some other file.
I'm wondering if there isn't some common cause with the WinXP failure that
Brian found a work around for.
Revision 104 Changes Handle 'pos/'leftof/'rightof/'succ/'prev attributes
trunk/canon.adb
Revision 105 Changes Handle -C and --mb-comments
trunk/ortho/gcc/lang.opt
Revision 106 Changes Switch to gcc 4.3
Don't use tagged types in grt (not supported by recent versions of GNAT)
Fix warnings (103 files)
trunk/canon.adb
trunk/disp_tree.adb
trunk/disp_vhdl.adb
trunk/errorout.adb
trunk/evaluation.adb
trunk/files_map.adb
trunk/flags.adb
trunk/ieee-vital_timing.adb
trunk/iir_chains.ads
trunk/iirs.adb
trunk/iirs.adb.in
trunk/iirs_utils.adb
trunk/libraries.adb
trunk/lists.adb
trunk/nodes.adb
trunk/ortho/debug/ortho_debug-disp.adb
trunk/ortho/debug/ortho_debug-main.adb
trunk/ortho/debug/ortho_debug.adb
trunk/ortho/debug/ortho_debug.private.ads
trunk/ortho/gcc/Makefile
trunk/ortho/gcc/Makefile.inc
trunk/ortho/gcc/ortho-lang.c
trunk/ortho/gcc/ortho_ident.adb
trunk/ortho/mcode/binary_file.adb
trunk/ortho/mcode/binary_file.ads
trunk/ortho/mcode/disa_x86.adb
trunk/ortho/mcode/ortho_code-decls.adb
trunk/ortho/mcode/ortho_code-disps.adb
trunk/ortho/mcode/ortho_code-dwarf.adb
trunk/ortho/mcode/ortho_code-exprs.adb
trunk/ortho/mcode/ortho_code-opts.adb
trunk/ortho/mcode/ortho_code-types.adb
trunk/ortho/mcode/ortho_code-x86-abi.adb
trunk/ortho/mcode/ortho_code-x86-abi.ads
trunk/ortho/mcode/ortho_code-x86-emits.adb
trunk/ortho/mcode/ortho_code-x86-insns.adb
trunk/ortho/mcode/ortho_ident.adb
trunk/ortho/mcode/ortho_mcode.adb
trunk/parse.adb
trunk/scan.adb
trunk/sem.adb
trunk/sem_decls.adb
trunk/sem_expr.adb
trunk/sem_names.adb
trunk/sem_scopes.adb
trunk/sem_specs.adb
trunk/sem_stmts.adb
trunk/sem_types.adb
trunk/std_package.adb
trunk/translate/Makefile
trunk/translate/gcc/Make-lang.in
trunk/translate/gcc/dist-common.sh
trunk/translate/gcc/dist.sh
trunk/translate/ghdldrv/Makefile
trunk/translate/ghdldrv/ghdlcomp.adb
trunk/translate/ghdldrv/ghdldrv.adb
trunk/translate/ghdldrv/ghdllocal.adb
trunk/translate/ghdldrv/ghdlmain.adb
trunk/translate/ghdldrv/ghdlprint.adb
trunk/translate/ghdldrv/ghdlrun.adb
trunk/translate/grt/Makefile
trunk/translate/grt/Makefile.inc
trunk/translate/grt/grt-astdio.adb
trunk/translate/grt/grt-avhpi.adb
trunk/translate/grt/grt-c.ads
trunk/translate/grt/grt-disp.adb
trunk/translate/grt/grt-disp_rti.adb
trunk/translate/grt/grt-disp_signals.adb
trunk/translate/grt/grt-disp_tree.adb
trunk/translate/grt/grt-errors.adb
trunk/translate/grt/grt-files.adb
trunk/translate/grt/grt-files.ads
trunk/translate/grt/grt-images.adb
trunk/translate/grt/grt-images.ads
trunk/translate/grt/grt-lib.adb
trunk/translate/grt/grt-main.adb
trunk/translate/grt/grt-modules.adb
trunk/translate/grt/grt-names.adb
trunk/translate/grt/grt-options.adb
trunk/translate/grt/grt-processes.adb
trunk/translate/grt/grt-processes.ads
trunk/translate/grt/grt-rtis_addr.adb
trunk/translate/grt/grt-rtis_utils.adb
trunk/translate/grt/grt-sdf.adb
trunk/translate/grt/grt-signals.adb
trunk/translate/grt/grt-signals.ads
trunk/translate/grt/grt-stats.adb
trunk/translate/grt/grt-table.adb added
trunk/translate/grt/grt-table.ads added
trunk/translate/grt/grt-unithread.adb
trunk/translate/grt/grt-unithread.ads
trunk/translate/grt/grt-vcd.adb
trunk/translate/grt/grt-vcd.ads
trunk/translate/grt/grt-vcdz.adb
trunk/translate/grt/grt-vital_annotate.adb
trunk/translate/grt/grt-vital_annotate.ads
trunk/translate/grt/grt-vpi.adb
trunk/translate/grt/grt-vstrings.adb
trunk/translate/grt/grt-waves.adb
trunk/translate/grt/grt.adc
trunk/translate/trans_analyzes.adb
trunk/translate/trans_be.adb
trunk/translate/translation.adb
Revision 107 Changes Bug fix: elaboration of direct drivers for
unconstrained array signals
trunk/translate/translation.adb
Revision 108 Changes Updated (now compiled with GNAT GPL 2008)
trunk/translate/gcc/README
A lot of the revision 106 changes are probably for warnings that show up
during builds (they were noticeable building revision 103). The fair money
is something in there, or something that was missed caused the Mac OS X
failure in revision 108.
Maybe not.
I stopped and chewed on the issue with ortho_code-x86-flags.ads in revision
103 for a minute and went and looked in revision 143 (these are about 36 MB
built), saw the reference in translate/ghdldrv/Makefile, and went and looked
at the produced ortho_code-x86-flags.ads in the build directory
(translate/ghdldrv):
with Ortho_Code.X86.Flags_Linux;
package Ortho_Code.X86.Flags renames Ortho_Code.X86.Flags_Linux;
We go back and look in ortho/mcode/ortho_code-x86-flags_linux.ads and we find:
Stack_Boundary : constant Unsigned_32 := 2 ** 3;
versus
Stack_Boundary : constant Unsigned_32 := 2 ** 4;
in ortho/mcode/ortho_code-x86-flags_macosx.ads.
It seems this is probably where the problem is.
I'll investigate who the build directory target for ortho_code-x86-flags.ads
is built, then give it a whirl. Seems the stack boundary specification
mechanism across target platforms isn't functional, at least in this case.
(And I don't feel bad about not looking at the contents of
ortho_code-x86-flags.ads).
>From revision 143 translate/ghdldrv/Makefile
#target=i686-pc-linux-gnu
target=i686-darwin
#target=x86_64-pc-linux-gnu
GRTSRCDIR=../grt
include $(GRTSRCDIR)/Makefile.inc
ifeq ($(filter-out i%86 linux,$(arch) $(osys)),)
ORTHO_X86_FLAGS=Flags_Linux
endif
ifeq ($(filter-out i%86 darwin%,$(arch) $(osys)),)
ORTHO_X86_FLAGS=Flags_Macosx
endif
ifdef ORTHO_X86_FLAGS
ORTHO_DEPS=ortho_code-x86-flags.ads
endif
ortho_code-x86-flags.ads:
echo "with Ortho_Code.X86.$(ORTHO_X86_FLAGS);" > $@
echo "package Ortho_Code.X86.Flags renames
Ortho_Code.X86.$(ORTHO_X86_FLAGS);" >> $@
This mechanism appears to have been put in place in revision 106.
I don't know anything about filter-out, my indepth experience predates it's
implementation. The question is whether or not the target
i686-darwin satisfies the filter, and apparently it does not.
ORTHO_X86_FLAGS doesn't show up before here in translate/ghdldrv/Makefile
and it doesn't come from ../grt/Makefile.inc either.
The default ORTHO_X86_FLAGS not matching either rule would be empty, and
results in the observed behavior fo the ortho_code-x86-flags.ads rule above.
The target simply doesn't match an applicable filter template.
The Quick Reference - GNU 'make' tells us
$(filter-out pattern...,text)
and to see Functions for String Substitution and Analysis.
It looks like i686 is $(arch) and darwin should be $(osys). The % in
darwin% in the rule:
>From $(patsubst pattern,replacement,text):
"Here pattern may contain a ‘%’ which acts as a wildcard, matching any
number of any characters within a word."
Does this mean it needs some number of characters (non zero number of chars)?
The rule may be in anticipation of building under Xcode, wherein we'd see
darwin9, darwin9.6 or darwin10 and the like. These specify binary
compatability and which architectures are present in a binary. (9.6 would
include i386 and x86_64, 10 would be only x86_64, which is why using the
wrong gcc doesn't build compatible C objects when your gcc is invoked
darwin10 only by default. The distinction isn't particularly interesting
when building ghdl today. We do need Stack_Boundary set correctly.
Macbook: make target=i686-darwin9.6 ortho_code-x86-flags.ads
echo "with Ortho_Code.X86.Flags_Macosx;" > ortho_code-x86-flags.ads
echo "package Ortho_Code.X86.Flags renames Ortho_Code.X86.Flags_Macosx;" >>
ortho_code-x86-flags.ads
(darwin9.6 applicable to Mac OS X 10.5)
This may explain why revision 103 worked, revision 108 failed as would
revision 106 likely, where the mechanism was put in place as well as a copy
of the ortho_codes-x86flags.ads being distributed in translate/ghdldrv.
To get a copy with the proper Stack_boundary you need to invoke the make for
ortho_code-x86-flags.ads directly and/or remove the existing copy. There is
no dependency on target.
After all that revision 143 still failed. A check of the differences again
to make sure nothing was polluted:
Macbook: cd /Applications
Macbook: svn diff ghdl
Index: ghdl/translate/ghdldrv/ortho_code-x86-flags.ads
===================================================================
--- ghdl/translate/ghdldrv/ortho_code-x86-flags.ads (revision 143)
+++ ghdl/translate/ghdldrv/ortho_code-x86-flags.ads (working copy)
@@ -1,2 +1,2 @@
-with Ortho_Code.X86.Flags_Linux;
-package Ortho_Code.X86.Flags renames Ortho_Code.X86.Flags_Linux;
+with Ortho_Code.X86.Flags_Macosx;
+package Ortho_Code.X86.Flags renames Ortho_Code.X86.Flags_Macosx;
Index: ghdl/translate/ghdldrv/Makefile
===================================================================
--- ghdl/translate/ghdldrv/Makefile (revision 143)
+++ ghdl/translate/ghdldrv/Makefile (working copy)
@@ -39,7 +39,8 @@
#GNAT_LARGS= -static
all: ghdl_mcode
-target=i686-pc-linux-gnu
+#target=i686-pc-linux-gnu
+target=i686-darwin
#target=x86_64-pc-linux-gnu
GRTSRCDIR=../grt
include $(GRTSRCDIR)/Makefile.inc
(I've been moving the built /Applications/ghdl directories to say
ghdl_revision_143, and copying them back as needed. That way I don't have
to download and build.)
There are no differences in 'effective' (source files other than the
Makefile and the purpose built ortho_code-x86-flags.ads file providing the
bigger Stack_Boundary for Mac OS X.
Back to slogging through revisions 104, 105, 106, and 107.
I may stop and see if the 2009 or 2010 gnat gpl darwin 9.6 releases from
AdaCore have any positive effect.
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
