FreeBSD - fre bug

[freebasic]

FreeBSD - fre bug

[rversteegen]

The implementation of FRE in FreeBSD is here: https://github.com/freebasic/fbc/blob/master/src/rtlib/freebsd/sys_fmem.c

As a FreeBSD user, perhaps you can work out what's wrong with it?

[vilhelmgray]

I'm willing to test this to verify if FRE still returns 0 in FreeBSD 12, but I'm not sure how to bootstrap a FreeBSD version of fbc -- it looks like the FreeBASIC bootstrap tarball is missing the FreeBSD code under the bootstrap/ directory. Is bootstrapping still supported for FreeBSD?

[dkl]

No, but I would expect doing what make bootstrap-dist does should work for going from Linux to FreeBSD too. (see also https://freebasic.net/wiki/wikka.php?wakka=DevBootstrap)

[rversteegen]

Bootstrapping works fine for FreeBSD, but you need to edit the makefile. In fact it works better than compiling from FreeBSD, which doesn't work (at least not with -gen gcc, haven't tried on x86 FreeBSD)

See https://github.com/rversteegen/fbc/commits/freebsd
Sorry, I need to make a pull request for those fixes. I'll try in coming days.
I do have FreeBSD 11 in a VM and can have a look at this bug too.

[vilhelmgray]

I compiled the following FreeBASIC program in x86-64 FreeBSD 12 using FreeBASIC 1.7.0:

Dim mem As Integer = Fre

Print "Free memory:"
Print
Print mem; " bytes"

After running the program, it successfully printed out my free memory. I was unable to recreate the issue described in the original report.

@fatman2021 Are you able to confirm that this issue is still present for you using the latest FreeBASIC release?

[jayrm]

@fatman2021,
Same here, I was unable to recreate the issue described in the original report.

Otherwise, fre returns something that seems reasonable (compared to value returned by $ sysctl hw.usermem), in fbc 1.07.1 built for:

• FreeBSD 12.0-i386
• FreeBSD 12.0-amd64
• seems OK for both bootstrap builds, and freebsd host rebuilds

fbc 1.07.1 is released with source-bootstrap for FreeBSD i386 & amd64. (compiled on Ubuntu 14.04 x86_64). Only issue I had was in selecting the correct ld at times ('ld' is probably using/receiving relative paths for finding some libraries), Manually solved this by invoking make as LD=/usr/local/bin/ld gmake when building fbc. I see @rversteegen has some improvements for fbc in this area, invoking gcc's ld instead of the system ld.

[rversteegen]

Oops. I forgot that I said I was going to send a pull request. I don't know when I'll get to it, juggling a lot of things.

[jayrm]

I don't know when I'll get to it, juggling a lot of things.

No worries. I was thinking about how I could make use of your work without making a big mess of it. Like maybe a rebase on top of fbc/master and then I could cherry pick only the commits that I am to able test & verify.

[vilhelmgray]

It's possible the FRE bug was present in an older version of FreeBASIC, but no longer in the recent releases. Perhaps this Github issue should be closed now that no one is able to recreate the bug with the latest version of FreeBASIC.

[jayrm]

Thanks @vilhelmgray. I agree.

[rversteegen]

The reason that my freebsd branch builds on top of my mac branch is because they both modify the crt headers in a way that intersects (Darwin was a fork of FreeBSD long ago and code has been shared back and forth since, so in particular many system headers are similar).
The unfinished crt header stuff is the primary reason that I never submitted pull requests for either my mac or freebsd branches. I only made enough changes to them so that the testcases, fbc and the OHRRPGCE would compile. But I think that's quite enough.