app is crashing! (GCC-compiled, FBC-generated C code)

[creek23]

Hoping to finally port my FB project from BAS to C, I finally tried out FBC 0.90.1 -- last I had was 0.24.

It's good to know that generating C code from BAS finally works right out of the box.

So, I tried compiling FBC_ROOT\examples\compression\zlib.bas via:

Code: Select all

fbc -gen gcc -R -m zlib -v zlib.bas

Then I got a ZLIB.C as well as ZLIB.EXE.

I tried to compile the ZLIB.C file by replicating what FBC did as shown by `verbose':

Code: Select all

FBC_ROOT\bin\win32\gcc.exe -m32 -S -nostdlib -nostdinc -Wall -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-main -Werror-implicit-function-declaration -O0 -fno-strict-aliasing -frounding-math -fno-math-errno -mtune=i486 "zlib.c" -o "zlib.asm"

FBC_ROOT\bin\win32\as.exe --32 --strip-local-absolute "zlib.asm" -o "zlib.o"

FBC_ROOT\bin\win32\ld.exe -o "MYZLIB.EXE" -subsystem console "FBC_ROOT\lib\win32\fbextra.x" --stack 1048576,1048576 -s -L "FBC_ROOT\lib\win32" -L "." "FBC_ROOT\lib\win32\crt2.o" "FBC_ROOT\lib\win32\crtbegin.o" "FBC_ROOT\lib\win32\fbrt0.o" "zlib.o" "-(" -lz -lfb -lgcc -lmsvcrt -lkernel32 -lmingw32 -lmingwex -lmoldname -lsupc++ -lgcc_eh "-)" "FBC_ROOT\lib\win32\crtend.o"

Then I got MYZLIB.EXE.

To my surprise, not only FBC could generate C code, GCC can actually compile the code!

Problem is, upon running both ZLIB.EXE and MYZLIB.EXE, the both crashed! :(

The output was:

Code: Select all

warning: different zlib version
zlib version 1.2.6 = 1260 compile flags = 55
uncompress(): hello, hello!
{crashed!}

Given the message saying, "warning: different zlib version", I tried recompiling ZLIB.BAS via `FBC ZLIB.BAS'.

Running the newly recompiled ZLIB.EXE worked like a charm.

Somehow, it seemed to be that the FBC-generated ASM file works better than the ASM file produced by AS.EXE from the FBC-generated C file.

Could this possibly a bug in the emitter? o.O

I know the emitter is not a top priority for the FBC dev team, but I'd like to know if anyone else had the same issue and had a workaround?


~creek23

[creek23]

Btw, I tried a very basic:

Code: Select all

DIM i AS INTEGER
i = 100

PRINT "helloworld"
PRINT "i is " & i

and it worked like a charm.

I just wanted to make the zlib.bas work because my FB project is way more complicated than the zlib.bas example. With zlib.bas failing to execute properly, I'm pretty sure mine won't work as well since it's also using zlib and some other libraries.

~creek23

[dkl]

I also see a crash during gzread() in test_gzio() on Linux with -gen gas/gcc, and I think that zlib example is broken, unfortunately:

Code: Select all

...
    uncompr =  @"garbage"

    if (gzread(file_, uncompr, uncomprLen) <> len_) then
...

There it's using a string literal as buffer and writing into it - that will fail when string literals are put into the read-only data section, which is the case on Linux and win32 -gen gcc, but not win32 -gen gas (that's how fbc did it since ever for whatever reason), which must be why it happens to work in that case.

I think that code was meant to be this:

Code: Select all

    assert( uncomprLen >= len( "garbage" ) + 1 )
    *cptr( zstring ptr, uncompr ) = "garbage"

    if (gzread(file_, uncompr, uncomprLen) <> len_) then

i.e. filling the uncompr with "garbage" before reading into it. That example really could use some simplification/clean up...

[dodicat]

Creek23.
I also tested a gcc compile with a slight modification of your shown switches.
The file was fbsq.bas, a bigint squaring function.
I used as a batch runner:
gcc.exe -m32 -nostdlib -nostdinc -Wall -O3 -c -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-main -Werror-implicit-function-declaration -O0 -fno-strict-aliasing -frounding-math -fno-math-errno -mtune=i486 fbsq.c
then
ar rcs Libsq.a fbsq.o
to give the library file.
It worked a treat, the included Libsq.a returned a good speed for the big int processing.
Thanks for these switches, just what I was looking for.

I have also made up a compressor and uncompressor with zlib in the past.
http://www.freebasic.net/forum/viewtopi ... 2A#p190797
But have not tried compiling C files by gcc for these.

[creek23]

I also see a crash during gzread() in test_gzio() on Linux with -gen gas/gcc, and I think that zlib example is broken

Thanks for looking into my problem, dkl.

Ignoring the issue on the zlib example, I tried doing -gen gcc with my project but I faced a different issue when compiling, which I stated on another thread -- I tried simple FBC (no -gen whatsoever), and still get the same issue.

~creek23

[creek23]

Thanks for these switches, just what I was looking for.

You're welcome! But I simply copied that from FBC -v's output.

~creek23