fb 1.07 tests

For other topics related to the FreeBASIC project or its community.
coderJeff
Site Admin
Posts: 3122
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: fb 1.07 tests

Postby coderJeff » Aug 31, 2019 23:16

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: 480
Joined: Jan 13, 2009 19:23

Re: fb 1.07 tests

Postby aloberoger » Sep 01, 2019 9:00

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: 5991
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: fb 1.07 tests

Postby dodicat » Sep 01, 2019 10:55

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: 1535
Joined: Jun 21, 2005 19:04

Re: fb 1.07 tests

Postby angros47 » Sep 01, 2019 11:41

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: 480
Joined: Jan 13, 2009 19:23

Re: fb 1.07 tests

Postby aloberoger » Sep 03, 2019 8:08

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=41995491388785972255
aloberoger
Posts: 480
Joined: Jan 13, 2009 19:23

Re: fb 1.07 tests

Postby aloberoger » Sep 03, 2019 8:24

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: 3122
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: fb 1.07 tests

Postby coderJeff » Sep 04, 2019 1:32

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: 480
Joined: Jan 13, 2009 19:23

Re: fb 1.07 tests

Postby aloberoger » Sep 04, 2019 18:56

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: 480
Joined: Jan 13, 2009 19:23

Re: fb 1.07 tests

Postby aloberoger » Sep 04, 2019 19:39

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: 3122
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: fb 1.07 tests

Postby coderJeff » Sep 08, 2019 12:39

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: 3122
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: fb 1.07 tests

Postby coderJeff » Sep 08, 2019 12:49

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: 480
Joined: Jan 13, 2009 19:23

Re: fb 1.07 tests

Postby aloberoger » Sep 08, 2019 16:30

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: 480
Joined: Jan 13, 2009 19:23

Re: fb 1.07 tests

Postby aloberoger » Sep 10, 2019 19:37

[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=55239919722881967242
coderJeff
Site Admin
Posts: 3122
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: fb 1.07 tests

Postby coderJeff » Sep 10, 2019 22:13

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: 480
Joined: Jan 13, 2009 19:23

Re: fb 1.07 tests

Postby aloberoger » Sep 11, 2019 17:34

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

Return to “Community Discussion”

Who is online

Users browsing this forum: Haubitze, srvaldez and 3 guests