search

adobe-flash / crossbridge

Welcome to visit the homepage!
http://www.crossbridge.io
542 stars 194 forks source link

Futures patches #52

Closed vpmedia closed 7 months ago

vpmedia commented 10 years ago

Hi, Please check the commits about changes, mostly I've improved the build Windows compatibility, and started to patch LLVM newer versions.

Best Regards!

vpmedia commented 10 years ago

Futures built with windows incl. log: https://dl.dropboxusercontent.com/u/1375050/cb_futures_sdk-win.zip

vpmedia commented 10 years ago

Travis build location (confirming that at part of the build is compiling under mac): https://travis-ci.org/vpmedia/crossbridge/builds

The project needs a dedicated CI server ideally both with Linux, Mac and Windows OSs. So if someone is able to provide that it would be fantastic.. Something like daily one basic build would be perfect, and weekly with full tests.

rtissera commented 10 years ago

Amazing work !!!!!

Since I have some interest in seeing this going alive, maybe I could provide the required CI dedicated server. Check your email.

mbolt35 commented 10 years ago

I'm getting llvm compile error on windows (cygwin): 

/crossbridge/llvm-3.2/lib/Target/AVM2/AVM2AsmPrinter.cpp:47:23: fatal error: uuid/uuid.h: No such file or directory
#include <uuid/uuid.h>

Any ideas?

rtissera commented 10 years ago

Yes you need libuuid Le 30 juin 2014 21:57, "Matt Bolt" notifications@github.com a écrit :

I'm getting llvm compile error on windows (cygwin):

/crossbridge/llvm-3.2/lib/Target/AVM2/AVM2AsmPrinter.cpp:47:23: fatal error: uuid/uuid.h: No such file or directory

include <uuid/uuid.h>

Any ideas?

— Reply to this email directly or view it on GitHub https://github.com/adobe-flash/crossbridge/pull/52#issuecomment-47578835 .

mbolt35 commented 10 years ago

Thanks! This got me much further. After this, I had to install lex (flex lexical analyzer) and also byacc -- I also had to create a symbolic link for /bin/yacc -> /bin/byacc as well as maybe a few other libs.

Now I've come across the following while compiling stdlib:

/crossbridge/build/win/lib/src/lib/libc/net/nsparser.y:169:4: warning: implicit declaration of function 'free' is invalid in C99 [-Wimplicit-function-declaration]
                    free((void*)elem);
                    ^
In file included from nsparser.c:398:
/crossbridge/build/win/lib/src/lib/libc/../../include/stdlib.h:93:7: error: conflicting types for 'free'
void     free(void *);
         ^
 /crossbridge/build/win/lib/src/lib/libc/net/nsparser.y:169:4: note: previous implicit declaration is here
                    free((void*)elem);

Is this due to something with my lex/yacc setup?

Cygwin setup packages listed for "yacc" image

And "lex" image

Hopefully you've dealt with this as well. Thanks again!

rtissera commented 10 years ago

Is Bison installed too ? Le 30 juin 2014 23:49, "Matt Bolt" notifications@github.com a écrit :

Thanks! This got me much further. After this, I had to install lex (flex lexical analyzer) and also byacc -- I also had to create a symbolic link for /bin/yacc -> /bin/byacc as well as maybe a few other libs.

Now I've come across the following while compiling stdlib:

/crossbridge/build/win/lib/src/lib/libc/net/nsparser.y:169:4: warning: implicit declaration of function 'free' is invalid in C99 [-Wimplicit-function-declaration] free((void)elem); ^ In file included from nsparser.c:398: /crossbridge/build/win/lib/src/lib/libc/../../include/stdlib.h:93:7: error: conflicting types for 'free' void free(void *); ^ /crossbridge/build/win/lib/src/lib/libc/net/nsparser.y:169:4: note: previous implicit declaration is here free((void)elem);

Is this due to something with my lex/yacc setup?

Cygwin setup packages listed for "yacc" [image: image] https://cloud.githubusercontent.com/assets/334480/3436385/36dde552-00a0-11e4-94a7-cf0d7b0ae1e3.png

And "lex" [image: image] https://cloud.githubusercontent.com/assets/334480/3436388/4cf796c6-00a0-11e4-9a94-a556246588b4.png

Hopefully you've dealt with this as well. Thanks again!

— Reply to this email directly or view it on GitHub https://github.com/adobe-flash/crossbridge/pull/52#issuecomment-47591952 .

mbolt35 commented 10 years ago

It was not installed, but I just installed it and ran stdlib build again -- failed with same error:

/crossbridge/build/win/lib/src/lib/libc/net/nsparser.y:169:4: warning: implicit declaration of function 'free' is invalid in C99 [-Wimplicit-function-declaration]
                        free((void*)elem);
                        ^
In file included from nsparser.c:398:
/crossbridge/build/win/lib/src/lib/libc/../../include/stdlib.h:93:7: error: conflicting types for 'free'
void     free(void *);
         ^
/crossbridge/build/win/lib/src/lib/libc/net/nsparser.y:169:4: note: previous implicit declaration is here
                        free((void*)elem);

It sure would be nice if the compiler would just tell me what it's conflicting with.

Update Part 1: Not sure exactly why this is the case, but I modified nsparser.c and commented out #include <stdlib.h> -- everything appears to be compiling now.

Update Part 2: My first update was the incorrect approach. It appears that once I had installed byacc, flex(lex analyzer), and bison, I needed to actually go back and re-compile from scratch. I ran into one more issue after this pertaining to the JAVA variable in the Makefile:

$?JAVA=$(call nativepath,$(shell which java))

In turns out that if your which java returns something like /cygpath/c/Program Files/Java/jdk/bin that nativepath or cygpath -at mixed /cygpath/c/Program Files/Java/jdk/bin will generate two paths:

The way I resolved this was by adding quotes in the JAVA definition:

$?JAVA=$(call nativepath,"$(shell which java)")

This should also probably be done for the PYTHON (maybe others) as well. Not sure why no one else has run into this issue, but I wanted to make sure that I pass the solution I used on in case it helps someone else. Thanks for all the assistance today rtissera.

vpmedia commented 10 years ago

Hi, I've solved the path name issue (spaces) using a batch script to launch cygwin for sdk building: https://github.com/vpmedia/crossbridge/blob/master/cygwin-dev.bat (Line34: set JAVA_HOME=/cygdrive/c/Progra~1/Java/jdk) Of course your solution using quotes seems more out-of-the-box for me, i'll try to modify the makefile (currently i'm working on the master branch to make it more up-to-date, so i'll start with that)

vpmedia commented 10 years ago

And in case of nasty compiler errors try using the -v flag to enable verbose mode

gcc -v -Wall hello.c

Many times a failing include path was the issue..

vpmedia commented 10 years ago

Since my first posts i've uploaded my cygwin distribution, maybe it helps for other users for faster starting, but i did not have the chance to test it out using VM boxes for other Windows versions than Win7: http://sourceforge.net/projects/crossbridge-community/files/cygwin-for-sdk-devs.zip/download

mbolt35 commented 10 years ago

Thanks for including that. I figured out that I had a lot of other problems because I had already built a cygwin version of clang (in my /usr/bin). When I switched over to your install, the previous issues that I had went away. I also ran this in Windows 7.

mbolt35 commented 10 years ago

Ok, so it seems after downloading your cygwin install, and executing a all_win build, I'm still getting a failure in extratools

A link to the log is here: extratools.txt

The two files the log mentions are zipped here: as3-e5OlHR.zip

Any thoughts were the issue might be?

vpmedia commented 10 years ago

Yes, right. I've opened an issue for this: https://github.com/vpmedia/crossbridge/issues/17 but I don't know how could be fixed as fast as possible (building a simple helloworld.c / cpp to SWF works - as far as I've checked the code generation works) I've wrote to @alexmac and his response was that according to the logs the compiler backend is crashing, also I've subscribed to LLVM mailing list but they could not help me out with this specific issue - I think maybe the swig.cxx code contains some nasty coding/typo error.

Edit: Anyway this was one of the main reasons why i've tried to upgrade LLVM to 3.3 or 3.4 but of course I've ran into other issues: https://github.com/vpmedia/crossbridge/issues/13 I'm not sure what's the standard procedure for debugging this kind of problem.. Any thoughts?

mbolt35 commented 10 years ago

One thing I did notice is that if I ran the .sh inside /tmp that it would correctly compile (although the .s would get up to 1GB in size before completing (possible cause of crash?). At first, I was tailing the .s output, and it appeared to be in some type of loop where the compiler would just output:

// EmitBytes

When you first execute the script, the .s output contains what looks to be valid AS3 "llvm assembly" until it reaches:

/*
Ltext_end
*/
// Ldata_end
/*
Lsection_end1
*/

At this point, it starts the EmitBytes looping:

// Linfo_begin1
// EmitBytes
// 0xD24B1600
// EmitBytes
// 0x0200
// EmitValueImpl
/* value: (Labbrev_begin) size: 4 */
// Not absolute
// EmitBytes
// 0x04
// EmitBytes
// 0x01
// EmitValueImpl
/* value: (Lstring0) size: 4 */
// Not absolute
// EmitBytes
// 0x0400
// EmitValueImpl
/* value: (Lstring1) size: 4 */
// Not absolute
// EmitBytes
// 0x00000000
// EmitValueImpl

The output looks very similar to the above for the remaining of the file, which is like I said, 1GB is size.

The last valid assembly that it outputs is this:

/*
Lfunc_begin3665
*/
;[Weak]
[GlobalMethod]
public function F__ZN3AS3D2Ev():void {
    var esp:int = ESP
    var ebp:int
Ltmp28791:;
    ebp = esp
    esp -= 16
    i0 = (li32(ebp))
    si32(i0, ebp-4)
    esp -= 16
Ltmp28792:;
Ltmp28793:;
    si32(i0, esp)
    ESP = esp
    F__ZN8LanguageD2Ev()
    esp += 16
    esp = ebp
    ESP = esp
    return
Ltmp28794:;
    var i0:int
} // function end

/*
Lfunc_end3665
*/

Which appears to match the source .cpp file 

class AS3 : public Language { 
    // ....
    public: 
        AS3():package(NIL) {}
        // ...

So basically the ctor gets output, but it looks like nothing else does. I haven't looked closely at that source code, but class AS3 : public Language starts on line 190478 of the .cpp I included in the zip above if you dare try to figure out what's going on there :)

vpmedia commented 10 years ago

If I delete the content of method *virtual int top(Node n)** there is no compiler error, so I'm a bit closer to fix swig..

Edit:

The following condition broke the compiler:

 if (!CPlusPlus) {
  mem_layout = new CMemoryLayout(input_file);
  // Always C for the time being
  CMemoryLayout::Language lang =
  CPlusPlus ? CMemoryLayout::CXX : CMemoryLayout::C;
  mem_layout->init(lang);
 }

Edit 2: I think the problem lies in the CMemoryLayout custom class.. SWIG still does not compiles:

mv -f $depbase.Tpo $depbase.Po
clang++  -I/cygdrive/f/crossbridge-futures/avm2_env/misc/ -I/cygdrive/f/crossbridge-futures/llvm-3.2
/include -I/cygdrive/f/crossbridge-futures/build/win/llvm-debug/include  -I/cygdrive/f/crossbridge-f
utures/llvm-3.2/tools/clang/include -I/cygdrive/f/crossbridge-futures/build/win/llvm-debug/tools/cla
ng/include -I/cygdrive/f/crossbridge-futures/llvm-3.2/tools/clang/lib -D__STDC_LIMIT_MACROS -D__STDC
_CONSTANT_MACROS -fno-rtti -g -Wno-long-long   -L/cygdrive/f/crossbridge-futures/build/win/llvm-debu
g/lib -o eswig CParse/cscanner.o CParse/parser.o CParse/templ.o CParse/util.o DOH/base.o DOH/file.o
DOH/fio.o DOH/hash.o DOH/list.o DOH/memory.o DOH/string.o DOH/void.o Modules/allegrocl.o Modules/all
ocate.o Modules/as3.o Modules/browser.o Modules/cffi.o Modules/chicken.o Modules/clisp.o Modules/con
tract.o Modules/csharp.o Modules/d.o Modules/directors.o Modules/emit.o Modules/go.o Modules/guile.o
 Modules/java.o Modules/lang.o Modules/lua.o Modules/main.o Modules/modula3.o Modules/module.o Modul
es/mzscheme.o Modules/nested.o Modules/ocaml.o Modules/octave.o Modules/overload.o Modules/perl5.o M
odules/php.o Modules/pike.o Modules/python.o Modules/r.o Modules/ruby.o Modules/s-exp.o Modules/swig
main.o Modules/tcl8.o Modules/typepass.o Modules/uffi.o Modules/utils.o Modules/xml.o Preprocessor/c
pp.o Preprocessor/expr.o Swig/cwrap.o Swig/deprecate.o Swig/error.o Swig/fragment.o Swig/getopt.o Sw
ig/include.o Swig/misc.o Swig/naming.o Swig/parms.o Swig/scanner.o Swig/stype.o Swig/symbol.o Swig/t
ree.o Swig/typeobj.o Swig/typemap.o Swig/typesys.o Swig/wrapfunc.o  -lLLVMAVM2Info -lLLVMAVM2CodeGen
 -lLLVMAVM2AsmParser -lLLVMAsmPrinter -lLLVMMCParser -lLLVMSelectionDAG -lLLVMCodeGen -lLLVMTarget -
lLLVMMC -lLLVMScalarOpts -lLLVMTransformUtils -lLLVMAnalysis -lLLVMCore -lLLVMSupport -lclangEdit -l
clangFrontend -lclangCodeGen -lclangDriver -lclangParse -lclangSema -lclangAnalysis -lclangLex -lcla
ngAST -lclangBasic -lclangSerialization  -L/cygdrive/f/crossbridge-futures/build/win/swig/pcre/pcre-
swig-install/lib -Wl,-R/cygdrive/f/crossbridge-futures/build/win/swig/pcre/pcre-swig-install/lib -lp
cre
Picked up _JAVA_OPTIONS: -Xms256m -Xmx4096m
/cygdrive/f/crossbridge-futures/sdk/usr/bin/ld: error: LLVMSupport: member at 753224 is not an ELF object
Modules/as3.o: error: undefined reference to '__ZN4llvm13StringMapImpl15LookupBucketForENS_9StringRefE'
Modules/as3.o: error: undefined reference to '__ZN4llvm13StringMapImpl11RehashTableEv'
Modules/as3.o: error: undefined reference to '__ZNK4llvm13StringMapImpl7FindKeyENS_9StringRefE'
rtissera commented 10 years ago

Keep up the good work !

2014-07-03 14:40 GMT+02:00 Andras Csizmadia notifications@github.com:

If I delete the content of method virtual int top(Node *n) there is no compiler error, so I'm a bit closer to fix swig..

— Reply to this email directly or view it on GitHub https://github.com/adobe-flash/crossbridge/pull/52#issuecomment-47924186 .

vpmedia commented 10 years ago

Just for note, I've noticed similar crashes like with SWIG when compiling DMalloc:

rtissera commented 10 years ago

So it crashes only when generating debug info WITHOUT generating LLVM bitcode but straight AVM2.

2014-07-05 18:12 GMT+02:00 Andras Csizmadia notifications@github.com:

Just for note, I've noticed similar crashes like with SWIG compiling DMalloc:

  • clang -g -O2 -> CRASHES
  • clang -g -O1 - > CRASHES
  • clang -O2 - > WORKS
  • clang -g -O4 - > WORKS

— Reply to this email directly or view it on GitHub https://github.com/adobe-flash/crossbridge/pull/52#issuecomment-48089997 .

mbolt35 commented 10 years ago

Related to the optimization flags: FlasCC Forums: tracking memory bugs

Unfortunately neither _falcan0 or myself were able to track down the cause of this issue. It seems as if it's related to the compiler replacing code which might be an optimization in most assembly creating unwelcome circumstances in the generated AS3 assembly.

mbolt35 commented 10 years ago

I also went through this once and didn't see anything too obvious that stuck out as "wrong:" SWIG 3.0 - Writing a Language Module

I also diff'd version 2.0 and 3.0 of the docs to see if there were any major updates, but found only typo corrections.All CMemoryLayout appears to be doing is initializing clang and llvm diagnostics? Perhaps this is where the incompatibility is (since we're using a new version of both). I'll check the docs there to see if I can debug further.

Wrote a pretty long update on the SWIG status here: https://github.com/vpmedia/crossbridge/issues/17