[Nasm-bugs] [Bug 3392532] panic: assertion pass0 == 0 failed at output/outobj.c:1915

[noreply-nasm at gorcunov.org]

https://bugzilla.nasm.us/show_bug.cgi?id=3392532

--- Comment #14 from H. Peter Anvin <hpa at zytor.com> ---
Realistically, I believe that we are going to have to support OMF for the
forseeable future.  It seems rather crazy to have to shoehorn support for
segmented architecture into a modern format; if nothing else we would have to
create some *massive* extensions that we then would have to convince a linker
to support, and so on.

For OMF, the entire OpenWatcom toolchain is available, including a decent
segment-supporting C compiler and linker.

That being said, I would love it if someone could find a way to get SAS to
re-license it under a true Open Source license.

I'm not personally opposed to adding NASM support either for an extended ELF
format, but the big question is getting support elsewhere.

I'm glad to see after numerous false starts (including one by myself) of
creating an ia16-gcc it looks like there is now some corporate backing by
Mentor, so hopefully it means that it might actually become a reality.

It is, however, worth noting that there is a *huge* difference between the kind
of code you want to produce for real mode on 386+ versus 8086/186/286, and a
proper ia16-gcc would have to be able to do either in order to not bloat the
code excessively.

As far as the assert is concerned, I believe I added it due to the issue we had
with segment convergence a while ago; I was hoping, I guess, that it would get
flagged if anyone tested it and there was a problem.  Another thing to add to
the 2.14.01 list.

stsp at list.ru: any reason you can't install NASM 2.14 locally and try to
reproduce? We even have automatic DOS builds available.

It is quite possible that the assert can be reduced to (pass0 < 2).  If we ever
get there with (pass0 == 2), we either need to throw an error due to
convergence failure, or we have an internal error.  An error would be
appropriate if someone has abused __PASS__, of course, but it makes it far
harder to track down an internal logic error.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are watching all bug changes.