fb 1.07 tests

General discussion for topics related to the FreeBASIC project or its community.
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: fb 1.07 tests

Post by coderJeff »

angros47 wrote:I remind that, for the DOS version of Freebasic, the file "makesymbr.bas" in the directory src/rtlib/dos should be compiled, then makesymbr.bas should be executed, and after that, the runtime library should be compiled again. It's the only way to keep dynamic linking symbols up to date for the DOS version
Yup, dang it. I definititely forgot to do that. Seems like this could (and should) be made an automatic part of the make file, despite the circular dependency within the rtlib. I think I see a couple of steps that could make this happen:

Separate exports module:

1) build rtlib, no exports, no symb_reg.txt
2) dxe3gen, symb_reg.txt, etc
3) move dlregsym(libfb_symbol_table) to separate module
4) compile the exports module as separate step

Complete rtlib as two files

Option 1) build rtlib (no-exports) first, followed by rtlib (with exports), using different file names. The final filename would be the rtlib normally used, and no changes are needed to fbc compiler, only the build process

Option 2) build rtlib (no-exports), and exports module (separately), then modify fbc compiler to link the exports module as additional module in the build step of an executable.

I fear that if we don't get this made part of the build process, then I am destined to forget again.
aloberoger
Posts: 507
Joined: Jan 13, 2009 19:23

Re: fb 1.07 tests

Post by aloberoger »

If you use fbc 1.05, 1.06, or 1.07, you must use the same version to build everything: DLL, static library, executable.
Currently I use the fbc 1.06 and I wanted to definitely go to the new version, unfortunately I am obliged for the moment to stick to 1.06 version while waiting better.

I will continue my investigations.

surprising even though a code that compiles and executes normally, when you create a library code no longer runs.
dodicat
Posts: 7976
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: fb 1.07 tests

Post by dodicat »

I downloaded your project afresh from this thread. (member aloberoger)
I popped in the disphelper lib file (was needed)
I commented out
'#Include Once "Win/vssym32.bi"
from TTable.bi
I went back to fb1.06 and tried to compile TestEdit.bas.
I get the errors
viz:
\TestEdit.bas(57) warning 4(1): Suspicious pointer assignment
\TestEdit.o:fake:(.text+0x110): undefined reference to `TFORM::MAINFORM__set__(int)@8'
\TestEdit.o:fake:(.text+0x126): undefined reference to `TFORM::BORDERSTYLE__set__(long)@8'
\TestEdit.o:fake:(.text+0x14a): undefined reference to `TFORM::VISIBLE__set__(int)@8'
\TestEdit.o:fake:(.text+0x200): undefined reference to `TCONTROL::VISIBLE__set__(long)@8'
l\TestEdit.o:fake:(.text+0x21b): undefined reference to `TCONTROL::COLOR__set__(long)@8'
. . .
. . .

I tested -gen gas and -gen gcc.

I then flipped over to fb 1.07 32 bit
I get the same errors as above.

I tested some of my own fb 1.06 dll's, albeit they are much simpler than FBCguitk.dll, they run OK on fb 1.07.

Sorry for waffling on but my main point is that with my fb 1.06 distro I get those compile errors shown above.
angros47
Posts: 2321
Joined: Jun 21, 2005 19:04

Re: fb 1.07 tests

Post by angros47 »

coderJeff wrote:Option 1) build rtlib (no-exports) first, followed by rtlib (with exports), using different file names. The final filename would be the rtlib normally used, and no changes are needed to fbc compiler, only the build process

Option 2) build rtlib (no-exports), and exports module (separately), then modify fbc compiler to link the exports module as additional module in the build step of an executable.

I fear that if we don't get this made part of the build process, then I am destined to forget again.
I think Option 1 is the best one, it would just made the building process a bit longer. I have no idea of how to modify the makefile to do that, unfortunately
aloberoger
Posts: 507
Joined: Jan 13, 2009 19:23

Re: fb 1.07 tests

Post by aloberoger »

dodicat wrote
I went back to fb1.06 and tried to compile TestEdit.bas.
I get the errors
here is all the project you can compile yourself with FB1.07 all things are OK
http://s000.tinyupload.com/?file_id=419 ... 8785972255
aloberoger
Posts: 507
Joined: Jan 13, 2009 19:23

Re: fb 1.07 tests

Post by aloberoger »

I wrote:
surprising even though a code that compiles and executes normally, when you create a library code no longer runs.
not true.

I thought I was creating the library because the library already existed with a previous version. the library was not created alone the asm file is created.
command : C: \ Program Files (x86) \ FreeBASIC1.07 \ fbc -lib) GUIS.1.0.bas "" GUIS.1.0.rc "


two questions result:

1) what can be the cause of the fact that instead of the library it is the asm file which is created
2) how to explain that with FB1.06 it's good but not with FB1.07
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: fb 1.07 tests

Post by coderJeff »

aloberoger wrote:1) what can be the cause of the fact that instead of the library it is the asm file which is created
I don't know about that one. Try compiling with '-v' command line option, and see more detail of what's actually happening. Are there any other extra command line options given (like from an IDE)?
2) how to explain that with FB1.06 it's good but not with FB1.07
First to explain why 1.05 library seems to be "good" in 1.06, when actually it's not.

Before fbc 1.06, fbc's integer & long types, did not map well C's long and int types, they were actually reversed. But mostly nobody noticed, because both were 32-bit. (The story continues in 64-bit, but is not important to this example).

1) In fbc 1.05 32-bit compile this library : fbc -lib a.bas

Code: Select all

sub proc overload( byval a as integer ) export
	print "integer"
end sub

sub proc         ( byval a as long    ) export
	print "long"
end sub
2) In fbc 1.05 32-bit compile this test: fbc b.bas -l a

Code: Select all

declare sub proc overload( byval a as integer )
declare sub proc         ( byval a as long    )

dim x as integer, y as long 

proc(x)
proc(y) 
OUTPUT:
integer
long

3) Now use the same 1.05 library with test compiled in fbc 1.06 (or 1.07):
OUTPUT:
long
integer

See the difference? It gives the appearance of working, but might actually be calling wrong procedures. Depends on the overloads defined and the complexity of the differences if you ever notice a bug or not.

2) how to explain that with FB1.06 it's good but not with FB1.07
Now for a library that was compiled in fb 1.06 (or fb 1.05) the difference is in the names of overloaded operator procedures that is stored in libraries. fb 1.06 & 1.05 used the wrong linking name for overloaded operator procedures. So if you have something like:

Code: Select all

type T
	__ as integer
end type
operator +( a as T, b as T ) as T
	'' ...
end operator
The linking name used is different in fbc 1.07, so a library compiled in an earlier version will not link to a program compiled in 1.07.


Conclusion:
fbc 1.05, 1.06, 1.07 each do something different when it comes to creating libraries. Specifically, the names that are used in the library when linking (can be static or dynamic). Do not mix a library created in one version with a program compiled in another version.
aloberoger
Posts: 507
Joined: Jan 13, 2009 19:23

Re: fb 1.07 tests

Post by aloberoger »

thank you for your explanations.

here is the command used and the output:
C:\Program Files (x86)\FreeBASIC1.07\fbc -lib -v "GUIS.1.0.bas" "GUIS.1.0.rc" -x "libGUIS.1.0.a"
FreeBASIC Compiler - Version 1.07.0 (08-25-2019), built for win32 (32bit)
Copyright (C) 2004-2019 The FreeBASIC development team.
standalone
target: win32, 486, 32bit
compiling: GUIS.1.0.bas -o GUIS.1.0.asm
C:\Users\Administrateur\Desktop\EXE-AUTO-2019\Mod\CGraphic.bas(493) warning 38(0): Suspicious logic operation, mixed boolean and non-boolean operands

Make done

I Noticed that the asm file GUIS.1.0.asm end with this;

call __ZN17TSIMPLEPANTOGRAPH14MAPREALTOPIXELEddRlS0_@28
mov eax, dword ptr [ebp+28]
lea ebx, [eax]
push ebx
push dword ptr [ebp-8]
push dword ptr [ebp-4]
mov ebx, dword ptr [ebp+8]
lea eax, [ebx+4]
pu

in my project I have the folowing procedure:

SUB TSimplePantograph.MapRealToPixel(x As Double, y as Double, byref i As Integer,ByRef j As Integer)
i = CInt( FPixelRect.Left + (x - FRealRect.Left) * FiDeltaOverxDelta)
j = CInt( FPixelRect.Top - (y - FRealRect.Top) * FjDeltaOveryDelta)
END Sub


for now I have removed this procedure and the library is created correctly. here is the -v option
C:\Program Files (x86)\FreeBASIC1.07\fbc -lib -v "GUIS.1.0.bas" "GUIS.1.0.rc" -x "libGUIS.1.0.a"
FreeBASIC Compiler - Version 1.07.0 (08-25-2019), built for win32 (32bit)
Copyright (C) 2004-2019 The FreeBASIC development team.
standalone
target: win32, 486, 32bit
compiling: GUIS.1.0.bas -o GUIS.1.0.asm
C:\Users\Administrateur\Desktop\EXE-AUTO-2019\Mod\CGraphic.bas(493) warning 38(0): Suspicious logic operation, mixed boolean and non-boolean operands
assembling: C:\Program Files (x86)\FreeBASIC1.07\bin\win32\as.exe --32 --strip-local-absolute "GUIS.1.0.asm" -o "GUIS.1.0.o"
compiling rc: C:\Program Files (x86)\FreeBASIC1.07\bin\win32\GoRC.exe /ni /nw /o /fo "GUIS.1.0.obj" "GUIS.1.0.rc"
creating: __fb_ct.inf.bas
compiling: __fb_ct.inf.bas -o __fb_ct.asm (FB compile-time info)
assembling: C:\Program Files (x86)\FreeBASIC1.07\bin\win32\as.exe --32 --strip-local-absolute "__fb_ct.asm" -o "__fb_ct.inf"
archiving: C:\Program Files (x86)\FreeBASIC1.07\bin\win32\ar.exe -rsc "libGUIS.1.0.a" "__fb_ct.inf" "GUIS.1.0.o" "GUIS.1.0.obj"

Make done
aloberoger
Posts: 507
Joined: Jan 13, 2009 19:23

Re: fb 1.07 tests

Post by aloberoger »

CoderJeff wrote
3) Now use the same 1.05 library with test compiled in fbc 1.06 (or 1.07):
OUTPUT:
long
integer

See the difference? It gives the appearance of working, but might actually be calling wrong procedures. Depends on the overloads defined and the complexity of the differences if you ever notice a bug or not.
to be simple what should we use integer or long? for 32bit FB


I came back and renamed the faulty procedure by:
SUB TSimplePantograph.MapRealToPixel(x As Double, y as Double, byref i As long,ByRef j As long)
i = CInt( FPixelRect.Left + (x - FRealRect.Left) * FiDeltaOverxDelta)
j = CInt( FPixelRect.Top - (y - FRealRect.Top) * FjDeltaOveryDelta)
END Sub
he same error was displayed
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: fb 1.07 tests

Post by coderJeff »

aloberoger wrote:I Noticed that the asm file GUIS.1.0.asm end with this;
call __ZN17TSIMPLEPANTOGRAPH14MAPREALTOPIXELEddRlS0_@28
mov eax, dword ptr [ebp+28]
lea ebx, [eax]
push ebx
push dword ptr [ebp-8]
push dword ptr [ebp-4]
mov ebx, dword ptr [ebp+8]
lea eax, [ebx+4]
pu
Does the asm file really end this way? If that's true, then fbc is aborting without error. Which would be really strange. Maybe an internal size limit? What happens when you remove other procedures, but keep that one? What if you only have that one and the smallest number of supporting procedures?

aloberoger, otherwise sorry, I don't know what would cause that.
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: fb 1.07 tests

Post by coderJeff »

aloberoger wrote: to be simple what should we use integer or long? for 32bit FB
If all your code is for 32-bit target only, and you are writing all your code in fbc, it probably doesn't matter.

However, it is important (even in 32-bit only) if you are linking your code (i.e. declarations) to libraries from other compilers, for example g++. fbc's "integer" and "long" types map to specific types in g++ (not just by size). If interested, for a detailed breakdown of mapping fbc's types to c/c++ types, see ALIAS (Modifier) / Data type mapping details.

Also, choosing integer or long is important, If you are going to compile your code for both 32-bit and 64-bit.
- fbc's long is always 32-bits.
- fbc's integer is 32-bits or 64-bits depending on target. (or 16-bit if compiling for #lang "qb")
aloberoger
Posts: 507
Joined: Jan 13, 2009 19:23

Re: fb 1.07 tests

Post by aloberoger »

coderjeff wrote
Does the asm file really end this way? If that's true, then fbc is aborting without error. Which would be really strange. Maybe an internal size limit? What happens when you remove other procedures, but keep that one? What if you only have that one and the smallest number of supporting procedures?
time to perform the different tests probably the result will be for tomorrow.
To successfully compile in reality I simply removed the entire class that contained the failed or abording code of the project

Does the asm file really end this way? If that's true, then fbc is aborting without error.
when I replace the class in question, I have the generated asm file again
aloberoger
Posts: 507
Joined: Jan 13, 2009 19:23

Re: fb 1.07 tests

Post by aloberoger »

[quote][/quote]
here is some code that seems to create a static library, but in fact just creates an asm file.
compile the file mapworldtopixel.bas
http://s000.tinyupload.com/?file_id=552 ... 2881967242
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: fb 1.07 tests

Post by coderJeff »

When I try it, In windows, I get a "fbc.exe has stopped working" application crash message pop-up. So yes, fbc.exe has died unexpectedly, and the ASM file, any part of it that might already be written, remains. What IDE/tool are you using to compile? I'm surprised you didn't get any indication that fbc had failed.

Thank-you for providing the example code to reproduce the problem.

After looking through your code, here is the pattern that is causing the crash:

Code: Select all

sub proc1( byval s as string )
end sub 
sub proc2( byref s as const string )
	proc1( cast(string, s) )
end sub
For some reason, this causes an endless recursion in the compiler when it tries to figure out how to assign cast(string, s) to a temporary variable, and passed it to the byval parameter in proc1(). It's a bug. And there are a few other variations that are also bug.

Easiest fix is to remove the cast. Passing a const string to a byval string parameter should be allowed. It should not warn even if compiled with -w constness command line option.

For example, this is OK:

Code: Select all

sub proc1( byval s as string )
end sub 
sub proc2( byref s as const string )
	proc1( s )
end sub
So is this:

Code: Select all

sub proc1( byval s as string )
end sub 
sub proc2( byref s as const string )
	proc1( cast(const string, s) )
end sub
And this (though you will get a warning if compiled with '-w constness' option):

Code: Select all

sub proc1( byref s as string )
end sub 
sub proc2( byref s as const string )
	proc1( cast(string, s) )
end sub
----

Created a bug report so is not lost: #910 cast(string, variable) can cause fbc to segfault (infinite recursion)
aloberoger
Posts: 507
Joined: Jan 13, 2009 19:23

Re: fb 1.07 tests

Post by aloberoger »

Coderjeff Wrote
What IDE/tool are you using to compile?
fbedit and fbide

I still want to remember that with FB1.5 that was correct.

like this oder example
Constructor Comobject (ByRef varSrc As Const VARIANT) Export
vt = VT_EMPTY
InternalCopy (@Cast (VARIANT,varSrc))
End Constructor

now you have to write:
Constructor Comobject (ByRef varSrc As Const VARIANT) Export
vt = VT_EMPTY
InternalCopy (Cast (VARIANT ptr, @ varSrc))
End Constructor
pending an improvement or fixation or something else, it seems appropriate to point out this as a mistake
Post Reply