I appreciate you guys digging in to the fbc 1.10 development. Thank-you.
__FB_ERR__ was always a bit masked type field, but up until 1.07.0 it could only have 4 possible values, 0,1,3,7. Internally it is INTEGER. Externally as presented to the user, it is literal text pasted in where used. Additional bits were added in 1.07.0 and later. Please consider higher number bits reserved for future use and should (now) always bitwise AND the __FB_ERR__ value with some mask to check values.
Code: Select all
'' __FB_ERR__ is actually literal text - not a typed symbol
#cmdline "-eunwind"
print __FB_QUOTE__( __FB_JOIN__( __FB_JOIN__( *, __FB_ERR__ ), * ) )
'' should print *512* if no other commandline options
'' that is, the following are equivalent
#print typeof(__FB_ERR__)
#print typeof(512)
IMHO, the stack unwinding and error handling are a hard problem and I wanted adeyblue (for as long as is interested) to be able to work on development. My intent with '-eunwind' was to only enable the new unwind code generation if specified, which would give SARG a chance to review changes in gas64 end on the main branch. But I see now I mucked it up with '-e'. So as of now, at the very least '-eunwind' should also be enabled for '-ex' and '-exx'. And maybe in future enabled by default (i.e. remove '-eunwind' option completely and fbc will do stack unwinding if the target supports it).
The difference of crash between 1.09.0 (and older versions) and 1.10.0 currently is due to gcc compile option '-fno-unwind-tables' changed to '-funwind-tables'. I didn't dig too deep. My guess is that either 64bit or newer mingw-w64/gcc expect certain structures (like unwind tables) to be present in signal handling. But I'm not sure, I could be making that up.
If there is enough participation in reviewing and trying to use (or break) the fbc development version, I feel like we could take a few more risks in attempting new features or changes. Basically, just going for it and see what the feed back is more often.