Hi Guys,

In working on the b0 compiler, I've noticed that the Linux build no longer assemblies using fasm. Since the Linux port doesn't use ld/gcc for the final executable (unlike all the other OSes), it's the only port effected by this.

The error is that a symbol is out of range when using the following instructions: eg:
lea rax, [_B0_argp]

(the b0.asm is roughly 1.5MB, executable around 200KB, and in memory size around 500MB).

If I build using:
format ELF64 executable, fasm stops.
format ELF64, fasm assemblies the source file fine, however I suspect this is due to the GOT.

Now I could understand if the variable was outside 2GB of the point that was needed (due to offsets being limited to 32bit when using 'lea', even on 64bit systems), however the total object size in memory is a tad under 500MB. (That's code, pre-defined data, and pre-defined BSS space).

So my question is, how does fasm calculate the segment offsets in memory for ELF64 executables, and is there any way to control those offsets? (It appears that the segments are being spaced too far apart when dealing with larger asm files).

Or does fasm request that the executable by placed in memory above the 4GB mark?

PS. On smaller test files, the 'lea' instructions works fine in both 'ELF64' and 'ELF64 executable' formats, it's just when the source and executables get bigger...

PPS. Source files attached.

I get a value out of range error at

Do you get the error at a different place with the attached sources?

When I use
I get _B0__atof_bcd = 00000000919943D4 which is too big to be encoded as a 32-bit immediate with sign extention. However if I do this minimal change:
I get _B0__atof_bcd = 00000000004293D4. So the jump added by the segment is huge and as far as I can see completely unjustified, I think there is a bug in fasm since if I use a small source with the same segments such terrible jumps does not exists.


Displays "0000000000402127" and has the same amount of segments in the same order.

Please confirm if you get the very same error or not because that could help in the bug tracking.

fasm 1.66 assembles it without tweaking anything in b0_elf_executable.asm.

There was a small bug in resolving - it's enough to change this kind of error to be of "recoverable" type (not signalized unless happened in the final pass) to fix this - 1.67.26 is going to have this fix included.

@Tomasz: Cool, just glad I wasn't missing something. (I hope you're glad I'm finding these problems on larger source files?)

@Loco: I was getting the error on a 'lea' just before that one you indicated. I hadn't thought to try an earlier fasm version, so thanks for checking.

I don't know if this has been resolved - I tried compiling the latest b0 and got this:



Cheers xD

I've tried the latest build on mine, and got the same error, so it doesn't look like it's been resolved?

PS. I took it for granted that the issue had been solved, and didn't retest it when the new FASM release came out.

Right, the bug was in two places and I fixed only one of them.
Will get fixed completely in 1.67.27

Wooohooo!