Porting FBC to FreeBSD on PowerPC64

[freebasic]

Porting FBC to FreeBSD on PowerPC64

[lenoil98]

Support is now included in recent release.

[rversteegen]

This looks familiar. Try cherrypicking this commit from my freebsd branch and see whether it fixes the problem:
rversteegen@6358184

[rversteegen]

Oh, by the way, is that big-endian or little-endian PowerPC? I haven't heard of anyone compiling fbc for PowerPC[64] before, and I don't think it fully supports big-endian CPUs; I'm aware of a few places there are endian assumptions. And although __FB_BIGENDIAN__ is documented on the wiki, it's never actually set! I have no idea whether big-endian targets are broken in a big or a little way.

[lenoil98]

Thanks for the assist. I'm picking through your commit to see if I can get this working. At the moment this is being done on big-endian PowerPC, but eventually I'll give it a try on little-endian. Will let you know what I find.

One thing I've noticed is that the presumption is cross compiling FBC on the host, while I was attempting to build on the target. Are you aware of any instructions on how to cross compile on a host?

[lenoil98]

Success!! I copied the crt1.o, crtbeginS.o, crtend.o, crti.o, crtsavres.o, crtbegin.o, crtbeginT.o, crtendS.o, crtn.o files to the FBC "lib" directory. Not sure if I needed to copy all of these files, but FBC now working. I was able to successfully compile hello.bas in the examples directory and it worked.

I'll look into whether there are endian issues as I explore FBC.

[lenoil98]

Can someone tell me where to set the default target in code?

[rversteegen]

Right, I guess you didn't try using that commit because of the trouble of re-bootstrapping. I was intending to include it with a related change Jeff and I were discussing recently.

One thing I've noticed is that the presumption is cross compiling FBC on the host, while I was attempting to build on the target. Are you aware of any instructions on how to cross compile on a host?

The question doesn't really make sense to me. fbc does correctly separate the host and the target. The -target commandline option changes the target.

The default target is FB_DEFAULT_TARGET. fb.bi contains:

#elseif defined(__FB_FREEBSD__)
const FB_HOST_EXEEXT        = ""
const FB_HOST_PATHDIV       = "/"
const FB_DEFAULT_TARGET     = FB_COMPTARGET_FREEBSD

If fbc was correctly crosscompiled by bootstrap-dist + bootstrap[-minimal], then the -target commandline option should have caused __FB_FREEBSD__ to be defined when fbc's .bas sources were compiled to .c, and therefore the default target should already be correct.

[rversteegen]

Oh, you were probably asking about how to set the default CPU arch. See FB_DEFAULT_CPUTYPE. However, fbc doesn't actually know about PowerPC, so you would have to add it.

[lenoil98]

Yes, that’s what I meant, default arch. I’ve already added definitions for POWERPC in fbc.bas. But it still defaults to x86_64. However, using -arch on the command line works.

[rversteegen]

There are some changes needed. I've created a branch for it, which you can get here:
https://github.com/rversteegen/fbc/commits/ppc
I added FB_DEFAULT_CPUTYPE_PPC[64] which I realised is likely going to conflict with the changes you made; sorry about that. You'll have to complete the rest of the PPC stuff.

I first added a __FB_X86__ define, which needed to do these changes in a clean way.

[lenoil98]

Great! I can make the necessary adjustments. I’ll give it a try and let you know.

[lenoil98]

I've incorporated your commits and made adjustments to my changes. You can find them here:
https://github.com/lenoil98/fbc
FBC compiles and seems to be working properly.

Thanks for all your help!

[rversteegen]

Great.

Looking at your patches I noticed you used FB_CVA_LIST_BUILTIN_C_STD on PowerPC[64]. This causes the compiler to assume va_list should be defined as

typedef struct __va_list_tag {
	unsigned int gp_offset;
	unsigned int fp_offset;
	void *overflow_arg_area;
	void *reg_save_area;
} va_list[1];

This looks incorrect. In GCC's va-ppc.h header I found a definition of __va_list for "System V.4" (as opposed to Apple/AIX, or Windows NT).

typedef struct __va_list_tag {
  unsigned char gpr;		/* index into the array of 8 GPRs stored in the
				   register save area gpr=0 corresponds to r3,
				   gpr=1 to r4, etc. */
  unsigned char fpr;		/* index into the array of 8 FPRs stored in the
				   register save area fpr=0 corresponds to f1,
				   fpr=1 to f2, etc. */
  char *overflow_arg_area;	/* location on stack that holds the next
				   overflow argument */
  char *reg_save_area;		/* where r3:r10 and f1:f8, if saved are stored */
} __va_list[1], __gnuc_va_list[1];

and https://github.com/lattera/freebsd/blob/401a161083850a9a4ce916f37520c084cff1543b/sys/powerpc/include/_types.h has an equivalent one.

I don't know whether we should add a new FB_CVA_LIST_ enum with the above struct definition, or just use FB_CVA_LIST_BUILTIN_POINTER. I'm not too familiar with it. Could you try changing it to FB_CVA_LIST_BUILTIN_POINTER and then see whether cva_list works? One way to do so would be to run the tests. Try make unit-tests and make log-tests. The latter are a bit harder to see the result of, look for
FAILED LOG - for log-tests -lang fb, FAILED LOG - for log-tests -lang qb, FAILED LOG - for log-tests -lang deprecated in the last couple of screens: it should say "None Found".

[lenoil98]

Okay, will make change and run tests. I also found another issue with “gcc” using -mcpu for PowerPC vice -march

[lenoil98]

I'm unable to run the unit-tests due to missing file "libfbcunit.a". When I try building the library i get:

`fbc -mt -g -exx -i ./inc -lib src/fbcunit.bas src/fbcunit_qb.bas src/fbcunit_console.bas src/fbcunit_report.bas -x lib/libfbcunit.a

/usr/local/include/freebasic/crt/stdio.bi(34) error 14: Expected identifier, found 'FILE' in 'declare function fopen (byval as zstring ptr, byval as zstring ptr) as FILE ptr'

/usr/local/include/freebasic/crt/stdio.bi(35) error 59: Illegal specification, at parameter 3 of freopen() in 'declare function freopen (byval as zstring ptr, byval as zstring ptr, byval as FILE ptr) as FILE ptr'

/usr/local/include/freebasic/crt/stdio.bi(36) error 59: Illegal specification, at parameter 1 of fflush() in 'declare function fflush (byval as FILE ptr) as long'

/usr/local/include/freebasic/crt/stdio.bi(37) error 59: Illegal specification, at parameter 1 of fclose() in 'declare function fclose (byval as FILE ptr) as long'

/usr/local/include/freebasic/crt/stdio.bi(39) error 14: Expected identifier, found 'FILE' in 'declare function tmpfile () as FILE ptr'

/usr/local/include/freebasic/crt/stdio.bi(42) error 59: Illegal specification, at parameter 1 of setvbuf() in 'declare function setvbuf (byval as FILE ptr, byval as zstring ptr, byval as long, byval as size_t) as long'

/usr/local/include/freebasic/crt/stdio.bi(43) error 59: Illegal specification, at parameter 1 of setbuf() in 'declare sub setbuf (byval as FILE ptr, byval as zstring ptr)'

/usr/local/include/freebasic/crt/stdio.bi(44) error 59: Illegal specification, at parameter 1 of fprintf() in 'declare function fprintf (byval as FILE ptr, byval as zstring ptr, ...) as long'

/usr/local/include/freebasic/crt/stdio.bi(47) error 59: Illegal specification, at parameter 1 of vfprintf() in 'declare function vfprintf (byval as FILE ptr, byval as zstring ptr, byval as va_list) as long'

/usr/local/include/freebasic/crt/stdio.bi(51) error 59: Illegal specification, at parameter 1 of vfscanf() in 'declare function vfscanf (byval as FILE ptr, byval as zstring ptr, byval as va_list) as long'

/usr/local/include/freebasic/crt/stdio.bi(51) error 133: Too many errors, exiting`

[lenoil98]

okay, got past this by adding:
#elseif defined(__FB_FREEBSD__) #include once "crt/freebsd/stdio.bi"
to crt/stdio.bi.

However, this caused errors for duplicated definitions for getwc, getwchar, putwc and putwchar. I temporarily commented those out so I could proceed with the unit-tests.

[rversteegen]

Yes, oops, I have a commit to get at least partially-working crt headers on FreeBSD. rversteegen@8082ee6
I don't remember whether my changes were enough to get all the log and unit tests to compile and pass.

However, any tests that fail because of FreeBSD header problems can be ignored. We only care about PPC-related problems right now.

[lenoil98]

I hit another roadblock when linking fbc-test. (See attached)
unit-tests.log

[rversteegen]

Ah, that's caused by using a bootstrap-minimal build, which doesn't include libfbgfx. Simply run make gfxlib2. And even if it doesn't build for some reason for you, most of the log-tests will still compile without it. And I think most of the tests related to cva_list are in log-tests anyway.

But it definitely would be good to have working a gfxlib2.

[rversteegen]

Oh sorry, I notice there's also an error at the bottom which is due to using a non-multithreaded libfb; bootstrap-minimal doesn't compile the multithreaded library either. So you have to compile that too, with make rtlib. And maybe make install it too if you're not running out of the source directory.

[lenoil98]

I built gfxlib2 and rtlib but I still get the same errors. There seems to be other issues with running the unit-tests.

I was able to run the log-tests, with pp/intrinsic-asm.bas is the only failed test.

[rversteegen]

Great. pp/intrinsic-asm.bas should already be fixed by my __FB_X86__ commit.
However I made a mistake, it turns out all the cva_list tests are in unit-tests not log-tests.

I tried it out, and it seems that objinfo (extra metadata embedded in .o files, used to tell which libraries should be automatically linked) is broken on FreeBSD, which is you can't build unit-tests. I can try to fix that later.

You should be able to get unit-tests to compile by editing tests/unit-tests.mk and adding -mt -l fbgfx to FBC_LFLAGS.

By the way, how do you want to be credited in readme.txt?

[lenoil98]

Finally got unit-tests to build. Needed to add X11 libs to FBC_LFLAGS and adjust the inc files.

fbc-test fails with errors:

  boolean/boolean_bitfield.bas(186) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_BITFIELD.ASSIGNMENT_SIGNED_VARIABLE CU_ASSERT_EQUAL(x.a,-1)
  boolean/boolean_bitfield.bas(195) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_BITFIELD.ASSIGNMENT_SIGNED_VARIABLE CU_ASSERT_EQUAL(x.b,-1)
  boolean/boolean_bitfield.bas(204) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_BITFIELD.ASSIGNMENT_SIGNED_VARIABLE CU_ASSERT_EQUAL(x.c,-1)
  boolean/boolean_bitfield.bas(157) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_BITFIELD.ASSIGNMENT_SIGNED_CONST CU_ASSERT_EQUAL(x.a,-1)
  boolean/boolean_bitfield.bas(166) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_BITFIELD.ASSIGNMENT_SIGNED_CONST CU_ASSERT_EQUAL(x.b,-1)
  boolean/boolean_bitfield.bas(175) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_BITFIELD.ASSIGNMENT_SIGNED_CONST CU_ASSERT_EQUAL(x.c,-1)
  boolean/boolean_bitfield.bas(129) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_BITFIELD.ASSIGNMENT_UNSIGNED_VARIABLE CU_ASSERT_EQUAL(x.a,-1)
  boolean/boolean_bitfield.bas(138) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_BITFIELD.ASSIGNMENT_UNSIGNED_VARIABLE CU_ASSERT_EQUAL(x.b,-1)
  boolean/boolean_bitfield.bas(147) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_BITFIELD.ASSIGNMENT_UNSIGNED_VARIABLE CU_ASSERT_EQUAL(x.c,-1)
  boolean/boolean_bitfield.bas(100) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_BITFIELD.ASSIGNMENT_UNSIGNED_CONST CU_ASSERT_EQUAL(x.a,-1)
  boolean/boolean_bitfield.bas(109) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_BITFIELD.ASSIGNMENT_UNSIGNED_CONST CU_ASSERT_EQUAL(x.b,-1)
  boolean/boolean_bitfield.bas(118) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_BITFIELD.ASSIGNMENT_UNSIGNED_CONST CU_ASSERT_EQUAL(x.c,-1)
  boolean/boolean_file.bas(80) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_FILE.IO_TEST_UTF16LE CU_ASSERT_EQUAL(b,(-1))
  boolean/boolean_file.bas(82) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_FILE.IO_TEST_UTF16LE CU_ASSERT_EQUAL(b,(-1))
  boolean/boolean_file.bas(85) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_FILE.IO_TEST_UTF16LE CU_ASSERT_EQUAL(b,(-1))
  boolean/boolean_file.bas(87) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_FILE.IO_TEST_UTF16LE CU_ASSERT_EQUAL(b,(-1))
  boolean/boolean_file.bas(90) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_FILE.IO_TEST_UTF16LE CU_ASSERT_EQUAL(b,(-1))
  boolean/boolean_file.bas(92) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_FILE.IO_TEST_UTF16LE CU_ASSERT_EQUAL(b,(-1))
  boolean/boolean_file.bas(104) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_FILE.IO_TEST_UTF16LE CU_ASSERT_EQUAL(x,wstr("false,true,false,true"))
  boolean/boolean_file.bas(106) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_FILE.IO_TEST_UTF16LE CU_ASSERT_EQUAL(x,wstr("false"+space(9)+"true"+space(10)+"false"+space(9)+"true"))
  boolean/boolean_file.bas(111) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_FILE.IO_TEST_UTF16LE CU_ASSERT_EQUAL(b,(-1))
  boolean/boolean_file.bas(113) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_FILE.IO_TEST_UTF16LE CU_ASSERT_EQUAL(b,(-1))
  boolean/boolean_file.bas(30) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_FILE.IO_TEST_ASCII CU_ASSERT_EQUAL(b,(-1))
  boolean/boolean_file.bas(32) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_FILE.IO_TEST_ASCII CU_ASSERT_EQUAL(b,(-1))
  boolean/boolean_file.bas(35) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_FILE.IO_TEST_ASCII CU_ASSERT_EQUAL(b,(-1))
  boolean/boolean_file.bas(37) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_FILE.IO_TEST_ASCII CU_ASSERT_EQUAL(b,(-1))
  boolean/boolean_file.bas(40) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_FILE.IO_TEST_ASCII CU_ASSERT_EQUAL(b,(-1))
  boolean/boolean_file.bas(42) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_FILE.IO_TEST_ASCII CU_ASSERT_EQUAL(b,(-1))
  boolean/boolean_file.bas(61) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_FILE.IO_TEST_ASCII CU_ASSERT_EQUAL(b,(-1))
  boolean/boolean_file.bas(63) : error : TESTS.FBC_TESTS.BOOLEAN_.BOOLEAN_FILE.IO_TEST_ASCII CU_ASSERT_EQUAL(b,(-1))
  file/encod.bas(34) : error : TESTS.FBC_TESTS.FILE_.ENCOD.READFROMFILE CU_FAIL_FATAL("couldn't open test file.")

[rversteegen]

What did you change on the inc files?

I investigated those errors. The boolean_bitfield.bas ones are due to #292. I'll leave that bug to someone else to fix. I found the bug which causes the boolean_file.bas ones, and in fact 2862 assert fails in total. (I didn't realise at first you hadn't posted all the errors.) I also see the encod.bas problem. I'm going to fix those and other obvious I/O endian bugs before asking you to try out the fixes.

[lenoil98]

I needed to comment out several lines in freebsd/wchar.bi. Take a look at my repository (https://github.com/lenoil98/fbc)

These were all the errors, the tests stopped at this point saying too many errors.

[lenoil98]

Been playing around with fbc attempting to compile some of the examples with some success. I've even been able to build wx-c and build the demo apps. However, when attempting to build the GTK demos I've encountered the header issues below:

/usr/local/include/freebasic/crt/sched.bi(47) error 59: Illegal specification, at parameter 2 (__t) of sched_rr_get_interval() in 'declare function sched_rr_get_interval(byval __pid as __pid_t, byval __t as timespec ptr) as long'
/usr/local/include/freebasic/crt/sched.bi(63) error 59: Illegal specification, at parameter 2 (__t) of __sched_rr_get_interval() in 'declare function __sched_rr_get_interval(byval __pid as __pid_t, byval __t as timespec ptr) as long'
/usr/local/include/freebasic/crt/pthread.bi(146) error 59: Illegal specification, at parameter 3 (__abstime) of pthread_timedjoin_np() in 'declare function pthread_timedjoin_np(byval __th as pthread_t, byval __thread_return as any ptr ptr, byval __abstime as const timespec ptr) as long'
/usr/local/include/freebasic/crt/pthread.bi(228) error 59: Illegal specification, at parameter 2 (__abstime) of pthread_mutex_timedlock() in 'declare function pthread_mutex_timedlock(byval __mutex as pthread_mutex_t ptr, byval __abstime as const timespec ptr) as long'
/usr/local/include/freebasic/crt/pthread.bi(252) error 59: Illegal specification, at parameter 2 (__abstime) of pthread_rwlock_timedrdlock() in 'declare function pthread_rwlock_timedrdlock(byval __rwlock as pthread_rwlock_t ptr, byval __abstime as const timespec ptr) as long'
/usr/local/include/freebasic/crt/pthread.bi(255) error 59: Illegal specification, at parameter 2 (__abstime) of pthread_rwlock_timedwrlock() in 'declare function pthread_rwlock_timedwrlock(byval __rwlock as pthread_rwlock_t ptr, byval __abstime as const timespec ptr) as long'
/usr/local/include/freebasic/crt/pthread.bi(268) error 59: Illegal specification, at parameter 3 (__abstime) of pthread_cond_timedwait() in 'declare function pthread_cond_timedwait(byval __cond as pthread_cond_t ptr, byval __mutex as pthread_mutex_t ptr, byval __abstime as const timespec ptr) as long'
/usr/local/include/freebasic/glib.bi(769) error 59: Illegal specification, at parameter 6 (stamp) of g_bookmark_file_set_app_info() in 'declare function g_bookmark_file_set_app_info(byval bookmark as GBookmarkFile ptr, byval uri as const gchar ptr, byval name as const gchar ptr, byval exec as const gchar ptr, byval count as gint, byval stamp as time_t, byval error as GError ptr ptr) as gboolean'
/usr/local/include/freebasic/glib.bi(770) error 59: Illegal specification, at parameter 6 (stamp) of g_bookmark_file_get_app_info() in 'declare function g_bookmark_file_get_app_info(byval bookmark as GBookmarkFile ptr, byval uri as const gchar ptr, byval name as const gchar ptr, byval exec as gchar ptr ptr, byval count as guint ptr, byval stamp as time_t ptr, byval error as GError ptr ptr) as gboolean'
/usr/local/include/freebasic/glib.bi(775) error 59: Illegal specification, at parameter 3 (added) of g_bookmark_file_set_added() in 'declare sub g_bookmark_file_set_added(byval bookmark as GBookmarkFile ptr, byval uri as const gchar ptr, byval added as time_t)'
/usr/local/include/freebasic/glib.bi(775) error 133: Too many errors, exiting

Looks like there are missing declarations in the headers. Any suggestions?

BTW, I've been successful in building wxFBE.

[lenoil98]

Okay found the cause of the errors. Needed to add new headers for FreeBSD. Will add them to my repo.

[lenoil98]

I’ve been experimenting with FBC for a while and I have been very pleased with the app. I’ve been able to successfully compile and run several apps like IUP_FB_Editor, wxfbe, and wxVisualDesigner, to name a few.

While satisfied with the current state, I know there’s more that needs to be done. But I wanted to provide a status update.

[rversteegen]

Glad you're still around and interested/working on this. I want to go through your FreeBSD and other changes and help to get them merged. I was making good progress on fixing all the big-endian file IO bugs when I got stopped to join the 7drl jam and disappeared; sorry about that. I'm working on 4 different languages plus numerous other projects...

[lenoil98]

Yes, I'm still interested and working this. I had an idea you were busy, that's why I didn't bug you. Let me know when and if you need my help.

regards

[lenoil98]

Attempted to run unit-test and encountered the below:

/root/Devel/fbc-new/tests/../bin/fbc -i /root/Devel/fbc-new/tests/../inc -c -w 3 -Wc -Wno-tautological-compare -i fbcunit/inc -m fbc-tests -mt functions/va_cva_api.bas
functions/va_cva_api.c:17:47: error: size of array '__$fb_structsizecheck' is negative
   17 | #define __FB_STATIC_ASSERT( expr ) extern int __$fb_structsizecheck[(expr) ? 1 : -1]
      |                                               ^~~~~~~~~~~~~~~~~~~~~
functions/va_cva_api.c:23:1: note: in expansion of macro '__FB_STATIC_ASSERT'
   23 | __FB_STATIC_ASSERT( sizeof( struct $N5TESTS9FBC_TESTS9FUNCTIONS10VA_CVA_API10UDT_VARARGE ) == 48 );
      | ^~~~~~~~~~~~~~~~~~
gmake[2]: *** [unit-tests.mk:133: functions/va_cva_api.o] Error 1

I get the same error on big and little endian. Any ideas?

[lenoil98]

Unknowingly my patches got mangled in the sync between my local host and GitHub. Some how the code reverted to the earlier version where FB_CVA_LIST_BUILTIN_C_STD was used for PowerPC instead of FB_CVA_LIST_BUILTIN_POINTER, per @rversteegen, which works.

There are still issues when running "fbc-tests". The tests seems to complete but with errors. See the attached file.

unit-tests.log

[jayrm]

@lenoil98, thank-you for attaching the unit-tests.log. Is this for PPC 64-bit little endian?

You will find that the unit-tests are good for checking results but not very good for debugging and finding the cause.
Often it is necessary to create a small test file that reproduces the problem and step through it in a debugger to understand the issue.

Tip: if you want to test a specific directory while searching for issues, for example 'overload' directory starting from the main directory:

$ cd tests 
$ rm -f unit-tests.inc 
$ gmake -f unit-tests.mk DIRLIST=overload FBC="`pwd`/../bin/fbc -i `pwd`/../inc"

Sometimes can have tests suddenly start to pass when tested on their own if the issue is some stack or memory corruption. Though I think is probably not the case here. Doesn't hurt to verify though.

I have ideas about some failures, but others will need more investigation. Sorry, I have no way to test PPC directly at the moment. If you happen to know an emulator and OS image that can work I will check it out.

numbers/infnan.bas

• see note in the source file
• ' The sign bit for NaN results is unspecified by IEEE754,
• ' and x86 and ARM differ in its selection.
• '' Little-endian assumption casting double ptr to ulongint ptr
• I would suspect there is some similar difference for PPC and possibly other issues if tested on big endian

hex_oct_bin_checks.bi

• not sure, investigate more to find out why the tests are failing

string/print_using.bas

• see note in the source file:
• '' arm targets only return NAN instead of IND? and different signs??
• #if not defined( __FB_ARM__ ) or ( ENABLE_CHECK_BUGS <> 0 )
• maybe is similar kind of issue for PPC?

threads/threadcall.bas

• the threadcall feature has mutliple issues. For now, just disable it for PPC and update the source comment
• #if not (defined( __FB_ARM__ ) or defined( __FB_DOS__) or defined( __FB_PPC__)) or ( ENABLE_CHECK_BUGS <> 0 )

wstring/midstmt.bas

• these number of failures is unexpected - weird
• seems to be something low level. An x86 assumption in the rtlib? A section of rtlib code needs to be gated with HOST_PPC?
• not sure, investigate more to find out why the tests are failing with a small test case in a debugger

wstring/print_using.bas

• see note in the source file:
• '' arm targets only return NAN instead of IND? and different signs??
• #if not defined( __FB_ARM__ ) or ( ENABLE_CHECK_BUGS <> 0 )
• maybe is similar kind of issue for PPC?

[lenoil98]

Yes, this is 64bit little endian, haven't rebooted to check big endian. @rversteegen open #292 for big endian.

Based on your input I'll investigate and provide my findings. I've seem in some cases if there are issues with ARM, there are similar issues with PPC.

[jayrm]

@lenoil98, I had some issues building the bootstrap package after #336. I think should be fixed now. See PR #340 for more info.

I've added -arch powerpc64le specifically for little endian plus some other fixes I haven't fully tested myself.

EDIT:
lol, I just noticed now that you made (some) same changes to the makefile days ago. :)

[lenoil98]

@jayrm Great work! Can’t wait to build and test your changes. Especially to see the unit tests results.

[lenoil98]

@jayrm, There are a couple of issues with build after #340.

Need to add powerpc64le to if( (fbGetCpuFamily( ) = FB_CPUFAMILY_PPC) orelse (fbGetCpuFamily( ) = FB_CPUFAMILY_PPC64) orelse (fbGetCpuFamily( ) = FB_CPUFAMILY_PPC64LE) ) then in fbc.bas to avoid error about -march=powerpc64 from GCC.

It looks like #if defined(__FB_BIGENDIAN__) in fb.bi is not working correctly. Evaluation always return false and build CPU is always "powerpc64le". I see it's defined in symb-define.bas but it seems to have no effect.

[jayrm]

@lenoil98
Ok, I will look at the -march=powerpc64 issue. Thanks for the tip.

It looks like #if defined(__FB_BIGENDIAN__) in fb.bi is not working correctly. Evaluation always return false and build CPU is always "powerpc64le". I see it's defined in symb-define.bas but it seems to have no effect.

__FB_BIGENDIAN__ certainly works for me when cross compiling (testing on windows even). However, fb.bi chooses a default cpu type based on the value of __FB_BIGENDIAN__ which is only recently added. So, the newly added support for it needs to built in to the compiler before building the bootstraps.

It should work if:

• build a latest version of fbc on your other system - on linux x86 for example
• build the bootstrap package with that latest version of fbc on linux x86
• take the bootstrap package to your powerpc systems and build a new ported fbc from that
• then, with the newly built fbc on the powerpc system, fbc source.bas should recognize correct default cpu type based on __FB_BIGENDIAN__

I haven't tested these steps exactly. Setting up powerpc with QEMU is more involved than I thought. But, so far for me and the tests I have done, I feel like this should work.

[lenoil98]

@jayrm

Thanks for pointing that out. I just built a new bootstrap package (same system). I then built the new fbc and everything seems to be working.

I do have one question, how do you get the linker to find the link files, when running "unit tests" or building the examples? Here's what I get when it attempts to link fbc-tests:
./pretest/compile_with_fbcunit.o() warning 20(3): Object files or libraries with mixed multithreading (-mt) options ./gfx/rgb_qb.o() warning 21(3): Object files or libraries with mixed language (-lang) options
error 23: File not found, crt1.o
error 23: File not found, crti.o
error 23: File not found, crtbegin.o
error 23: File not found, crtend.o
error 23: File not found, crtn.o
ld: error: unable to find library -lffi
ld: error: unable to find library -lX11
ld: error: unable to find library -lXext
ld: error: unable to find library -lXpm
ld: error: unable to find library -lXrandr
ld: error: unable to find library -lXrender
ld: error: unable to find library -lgcc
ld: error: unable to find library -lpthread
ld: error: unable to find library -lc
ld: error: unable to find library -lm
ld: error: unable to find library -lncurses
gmake[2]: *** [unit-tests.mk:179: build_tests] Error 1

[jayrm]

@lenoil98

I do have one question, how do you get the linker to find the link files, when running "unit tests" or building the examples?

Based on your error messages, it looks like objinfo is working to automatically add all the needed libraries. It's just not finding the proper library path.

I think it's a matter of native ld being used instead of ld.bfd because I can get a similar issue on freebsd-x86 if the native ld is invoked instead of ld.bfd. We are still relying on many gnu-isms with gmake, gcc, bfd, etc. So we're not quite there yet with a native freebsd build.

if fbc is installed to the system using gmake install, then this works ok for me:

# gmake install
$ cd tests && gmake unit-tests

But, if I specifically try to test a freshly built ./bin/fbc then currently need to to help gmake / fbc use ld.bfd and find the include files

$ cd tests && LD=ld.bfd gmake unit-tests "FBC=`pwd`/../bin/fbc -i `pwd`/../inc"

[lenoil98]

@jayrm

I think it's a matter of native ld being used instead of ld.bfd because I can get a similar issue on freebsd-x86 if the native ld is invoked instead of ld.bfd. We are still relying on many gnu-isms with gmake, gcc, bfd, etc. So we're not quite there yet with a native freebsd build.

Thanks for the explanation.

I'd just copied the "crt" files to /usr/local/lib/freebasic/freebsd-powerpc64 directory and using fbc -Wl -L/usr/local/lib on the fbc command-line. With this I've been able to experiment and successfully build wxFBE, IUP FB EDITOR and visualwxcdesigner. I even have a somewhat working VisualFBEditor on little endian (source files uft8-bom format not compatible with big endian).

[rversteegen]

@jayrm

I think it's a matter of native ld being used instead of ld.bfd because I can get a similar issue on freebsd-x86 if the native ld is invoked instead of ld.bfd. We are still relying on many gnu-isms with gmake, gcc, bfd, etc. So we're not quite there yet with a native freebsd build.

Thanks for the explanation.

But how come gcc -print-prog-name=ld returns ld.bfd when fbc is installed, but not when running from bin/ ? (c.f. 0d7d036)

(source files uft8-bom format not compatible with big endian).

I was working on that: https://github.com/rversteegen/fbc/commits/ppc
I only pushed testcases to github so far, but I also have unfinished fixes; IIRC I found the cause of that big-endian BOM breakage in both rtlib and the compiler's hCheckFileFormat.

[rversteegen]

Also, I can't remember whether those tests commits were finished or not.

[jayrm]

@rversteegen

But how come gcc -print-prog-name=ld returns ld.bfd when fbc is installed, but not when running from bin/ ? (c.f. 0d7d036)

Good question. I investigated more.

If fbc is installed and is invoked, then ld and as are found relative to the fbc install directory.
On my system ld is a copy of ld.bfd in /usr/local/bin/../bin/.

If fbc is invoked from the build directory, then behaviour depends on which backend:

• If -gen gcc backend is used, then ld name of ld.bfd is found because gcc is used to query the ld name.
• If -gen gas backend is used, then ../bin/ld is not found relative to fbc and so the system path is relied upon and ld is invoked instead in /usr/bin/

If fbc can't find the binary directly, then it relies on the system path.

So, one work around is to put symlinks for the binaries needed by fbc in the ./bin directory where fbc is located when outside of the normal install directory:
$ cd bin && ln -s /usr/bin/local/ld,bfd ld
which would allow ./bin/fbc to find ../bin/ld relative to itself.

[rversteegen]

If -gen gas backend is used, then ../bin/ld is not found relative to fbc and so the system path is relied upon and ld is invoked instead in /usr/bin/

Then maybe we should always query gcc for which ld to use on *BSD, even when using the gas backend, since we rely on the GNU toolchain. But it would be preferable to not depend on gcc when not actually using the gcc backend. Is there a better way? Default to ld.bfd if it exists?