[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 #16 from stsp at list.ru ---
(In reply to H. Peter Anvin from comment #14)
> 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.
While I agree with you in theory, I wonder
if this is true in details. For example, will
supporting "wrt" really need an elf extension?
I don't know the details, but the naive thinking
suggests it can be implemented entirely in compile-time.
"class" asks the linker to place the segments adjacently,
and I wonder if this requires an ELF extension, as it
looks quite simple. Etc. This is why I think the documentation
may be needed to get the clear picture of what this support
will look like if its there. If it is a matter of elf
extension, that's one thing. But if it can be rather easily
implemented on nasm level, then entirely different story.

> For OMF, the entire OpenWatcom toolchain is available, including a decent
> segment-supporting C compiler and linker.
Both projects have already passed the need of a watcom
C compiler, and freedos already passed the need of their
librarian/linker too. When you don't need to use watcom C,
you have very little reason to keep sticking with omf.

> 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 don't know what projects you have in mind, but for
freedos and its spin-offs (like fdpp) this is of no interest.
There is a gcc and/or clang port to invest the efforts,
not to go back to watcom. Both ports are already stable
(as in Beta), so there is no way back.

> 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 works already. But for what projects it is needed, exactly?
I am personally not so enthusiastic about the freedos port
on ia16gcc (which is why I forked it and ported to clang),
but I think you have some other projects in mind. Maybe
ia16gcc is good for seabios and the likes, I don't know.
In my opinion, ia16gcc is too late, something like 10-20
years too late to be relevant. Which is why I want to stay
away of it, and, consequently, of omf.

> 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.
If it will help in any way, I can do that of course.
No problems to build it from sources and test the fix.
But I am also fine with trying it on launchpad instead.

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