Cool Project supporting ELKS formats!

[ghaerr]

Hello @BinaryMelodies,

Just happened to run across your new project, pretty cool!! As it turns out, I'm pretty interested in a linker that might be able to do what it seems where you're going with RetroLinker.

In particular, at ELKS we're now dealing with three different object file formats and two executable formats: the kernel and main applications are compiled with ia16-elf-gcc using a modified 16-bit version of the 32-bit ELF format, post-processed by elf2elks and producing the ELKS a.out executable.

We more recently added support for OpenWatcom C with all its memory models and supporting more than a single code and data segment. For that, I extended the kernel to load 16-bit OS/2 NE format executables, with any number of code/data segments. We're using OWC's .obj (OMF) format object files and the wlink linker to produce the OS/2 NE executable, and the ELKS C library is also ported.

Just recently, we ported an 8086-toolchain as a host and native ELKS C compiler, which produces NASM or AS86 assembly source output producing the AS86 Introl-format .o object file format. I've gotten familiar with the AS86 .o format despite no documentation. That was then combined with the old dev86 as and ld (AS86 and LD86), for which a number of bug fixes and enhancements were added and LD86 used to an ELKS separate I&D a.out executable.

I'm now at the point of producing various disassemblers, object file dumpers, exe file dumpers and other utilities to better work with all these object and executable formats on the host and ELKS. These are mostly in the elks/tools/objtools/ directory in the ELKS repo, and 8086-toolchain/. I'm also revamping the ELKS a.out symbol table format to the older version used by LD86, although that's still restricted to 8 characters max.

Right now the 8086-toolchain is limited to using dev86 ld (LD86) as the linker, which is working well since its pretty simple but only works with AS86-compatible Introl-format .o files. This pretty much restricts the ability to use assembly source from OWC and other assemblers, and we've now got 3+ assembly source language variants to deal with.

So I remain interested in what you're doing! :)

On a separate note, I noticed on your ELKS fork commit 650a44ea5094c654c63191595ab3158cebf79a46 you updated some system calls and added ELKS_COMBID to elksemu. Would you like those changes added upstream? They look useful and would love to have them, although I don't know exactly why you've had to modify the brk system call operation. I'm assuming your linker is producing the ELKS_COMBID a.out variant also?

Anyways, thank you for a very interesting project. I am also interested in helping document AS86 .o file format and/or continue to develop other tools for inspection of the various object and executable file formats you're working with for RetroLinker.

Thank you!

[BinaryMelodies]

Hello ghaerr!

Thank you very much for the message and opening this issue! As I was preparing to publish the code, I was excited to notice some recent development on the ELKS project, some of which I would like to provide support for in the RetroLinker project as well.

It's interesting that you mention as86 and OpenWatcom since an earlier, unpublished prototype of this linker had read support for both the as86 object format and Intel's OMF, and it could function as a drop-in replacement for ld86 (and to a more restricted extent, for wlink). The current project is a full redesign/rewrite, so as86 and OMF support is currently stubbed out, but planned. If there is interest in supporting those formats, I would prioritize implementing those as well. (The reason they aren't implemented yet is because parsing both of them is a bit complex and error prone, and I already fully support the ELF format. Furthermore, I only had the dev86 sources for the as86 file format, so any further documentation would be appreciated!)

I didn't have time yet to look into the updates in the ELKS executable format aside from some precursory peek, but I would like to eventually update the MINIX (and NE) outputs to also provide support for these. Unfortunately I only use elksemu for testing the ELKS output, and that does not yet support the NE executable format.

I also have to point out that I consider the codebase to be in its alpha stage. In particular it has not been stress tested yet, and likely requires some polishing, but it has worked fine for smaller, personal projects.

I will respond to the elksemu related question in a separate comment.

Thank you again for expressing interest!

[BinaryMelodies]

I will respond to the questions related to elksemu here. First I want to clarify a few things, so you know what goals I had in mind with the modifications.

First, I reintroduced support for ELKS_COMBID because my linker supports both split and combined executables, and I wanted to be able to test them out on my native Linux computer. I assume ELKS_COMBID support was removed when elksemu switched from vm86 mode to 16-bit protected mode to support running ELKS executables natively on 64-bit Linux. I am not sure how robust running ELKS_COMBID executables in protected mode is, since the same memory area is exposed as executable as well as writable, but for basic tests it worked fine for me.

(As a side note, I had a separate, earlier modification to the elksemu sources where I switched over from vm86 support to CPU emulation using https://github.com/wfeldt/libx86emu, to permit running elksemu on 64-bit Linux, but I have not uploaded those changes. This could potentially be provided as an alternative for non-x86 platforms, if for example someone wants to test out ELKS binaries on a Raspberry Pi).

I implemented the new system calls because I wanted to provide access to the host networking stack. I am not sure how relevant this is for ELKS itself, if it has a functioning networking stack, but the system call numbers were allocated, so I used those. In particular, I could communicate with my X Window System from elksemu.

As for the change in the system call brk, I noticed that recent updates (late 2010s) broke binaries compiled using older versions of dev86 because the brk implementation was altered. To let me run those binaries without requiring a recompile, I added the --old and --new flags to elksemu, and the --old flag changes the numbers of those system calls, and replaces brk with the old version.

(I will also mention that I have some uncommitted changes that allow running ELF executables with elksemu, and I also tried adding MINIX 1/2 support. However, those need to be updated to the new elksemu version first)

In light of these, which additions would be relevant for your project? I assume including support for ELKS_COMBID could be interesting, if only for the sake of curiosity, and the additional system calls could be useful even without a native network stack for ELKS. However I don't expect that supporting the legacy brk system call is relevant for others. Aside from these, I would also gladly take time to introduce the extensions that used the x86emu emulation for non-x86 platforms, the ELF executable support, and I would also be interested in implementing OS/2 NE executable support (I have not checked what needs to be done for that though).

Also let me know what you would like to see specifically for RetroLinker, as I wanted to get around to as86 and OMF support eventually.

[ghaerr]

Looks like we have a lot to talk about!

There's been a huge number of changes to ELKS made over the last four years, so for now I'll just reply in more stream fashion.
I develop on macOS so have not been able to ever actually use elksemu, unfortunately. Since my development includes lots of kernel stuff, I use QEMU using an image prepared from the repo build, which usually allows for easy testing of ELKS applications as well. I built the blink16 which allows for complete system emulation, including an 8086 emulator, and 86sim which uses the same 8086 (real mode only) CPU emulator that will also run ELKS a.out executables. It's missing a full set of system call emulations though.

So I really don't have much directly comparable to elksemu, and haven't tracked its changes as closely. ELKS has a user-space TCP/IP implementation, and having your added system calls to elksemu is still a good idea, although the stack itself won't work without a bunch of messy kernel buffer passing etc. Thanks for the link on libx86emu, looks like a very interesting project, especially since the emulation is wrapped up as a library. The ELKS kernel is providing lots of more specialized services that might be hard to emulate without actually emulating the kernel also though.

Regarding COMBID and other a.out variants, ELKS doesn't current load that, although from your elksemu changes it looks like it just loads the data segment in the same segment after the text segment, instead of a separate data segment. ELKS already loads .data directly after .text (unless there's a .ftext section) so that could probably be easily added, except that I don't think that anyone actually uses dev86 to produce ELKS executables anymore.

On the note of ELKS a.out header changes, FYI there's been a number of enhancements: the older 32-bit "a_total" field, previously specifying the total data segment size (including extra heap) has been split in two and now "chmem" specifies the heap size (0=4K, 0xFFFF=max) and "minstack" specifies a "protected" stack size (0=4K), protected meaning the program break isn't allowed to overlap that area. There is an extended header which allows for a .fartext section (single max additional 64k code segment) as well as compressed executables, specifying compressed/uncompress sizes. Support for a stack area below the data segment has been removed. The previously unused (0) version number was incremented to 1 when the chmem/stack fields replaced a_total. ELKS still loads those executables, as I thought that is still the default produced by dev86, but we may drop those also at some point.

Thanks for the new/old brk explanations, I'm still a bit unclear as to exactly what was done in ELKS (long ago?) changing the sys_brk behaviour - perhaps this is a remnant of a fixed stack below the data segment, instead of above it?

Adding 16-bit OS/2 NE support was a little more ambitious - it required a slight rethink of the kernel's idea of having three fixed segments: .text, .ftext and .data. Instead, a fixed array in the task struct is allocated that allows for the arbitrary numbering of a fixed number of OS/2 NE's segments to be allocated and loading according to type. There are a few new relocations that need to be handled by the loader, but OpenWatcom only produces 2-3 variants and never the much larger set possible within the full OS/2 specification.

I had a separate, earlier modification to the elksemu sources where I switched over from vm86 support to CPU emulation using https://github.com/wfeldt/libx86emu,

That sounds very interesting nonetheless as a way to get familiarized with libc86emu!

I would also gladly take time to introduce the extensions that used the x86emu emulation for non-x86 platforms, the ELF executable support, and I would also be interested in implementing OS/2 NE executable support

If your changes might allow elksemu to run on Intel macOS, that would still be very interesting, given that I can't currently run elksemu. However, I think macOS lacks the ability to allocate low-level segment descriptors so that probably won't work. Direct ELF support is interesting, but very few 16-bit compilers support it. ia16-elf-gcc uses a special virtual address scheme and three symbols per actual symbol to denote .text, .ftext or .data, which isn't in the ELF spec. The OS/2 NE format is working quite well, especially with the large number of extensions supported by OWC. For more details on my OS/2 NE loader, see elks/fs/exec.c::exeve_os2().

Thank you for your comments!

[ghaerr]

you mention as86 and OpenWatcom since an earlier, unpublished prototype of this linker had read support for both the as86 object format and Intel's OMF, and it could function as a drop-in replacement for ld86 (and to a more restricted extent, for wlink).

Now that sounds very interesting, even if you don't plan on enhancing it and are currently redesigning everything. If you're willing, I'd like to take a look at that, since reading more source code always helps when trying to understand AS86 and OMF object formats!

I've finally got my hands around the (luckily smaller amount of OMF specification) that is actually produced by OpenWatcom, although all the specialized COMENT records seems to be a bit of black magic. At this point, we're not trying to link .obj's from OWC with other non-OWC objects, although such a thing is potentially interesting, from the standpoint of having to support only a single assembly language source format - as I mentioned previously, we're now having to deal with the somewhat ridiculous problem of GAS .s, AS86 .as, NASM .asm and WASM source files in three different object formats (ELF, Introl, OMF). Our old version of NASM in the 8086-toolchain project does support as86 Introl .o output, but still doesn't support .comm/common variables properly. We finally kicked out NASM completely when it was discovered that assembling the 39k output of a 550 line chess.c program required 15+ minutes on an 8088! AS86 handles the same in 10-20 seconds on the super slow machines. (NASM does thousands of mallocs, tons of symbol hashing, and way too many assembler passes).

The current project is a full redesign/rewrite, so as86 and OMF support is currently stubbed out, but planned. If there is interest in supporting those formats, I would prioritize implementing those as well.

I'm interested in AS86 object file support, for sure. OMF support would be nice also. But can your linker run compiled with a 16-bit compiler, or as an OS/2 NE executable? Having a host-based linker would be great, for sure, allowing for combining or using objects from ia16-elf-gcc as well as OpenWatcom (ELF and OMF). Our AS86 support is now available through both host and native ports of AS86 and LD86, which is pretty cool with the latter actually running on ELKS itself.

I only had the dev86 sources for the as86 file format, so any further documentation would be appreciated!)

I haven't actually written new documentation for the as86 .o object file format, but had to delve deep into the net and found some more documentation on the AS86 assembly input language, based on that language's start as IBM's PC/IX assembler. So, using that and dis88, a disassembler from 1988, along with as86 sources, I've been able to pretty accurately determine the assembly source language. The .o format understanding has come from reading dev86 as86, ld and objdump86 sources, along with the older NASM source file that generates as86 .o format. I also found that Introl was likely responsible for creating an object file format from which I'm pretty sure AS86 started with. You might know that as86 seems to have started as a 6809 assembler, and Introl was selling 6809 C compiler toolchains back in the day...

I plan on writing up the as86 object file and source language definition but haven't got that done yet.

[BinaryMelodies]

Hello! There's quite a lot to talk about here, and I don't think I will get around to all of them, so I will just mention a couple of things:

Yesterday I added as86 object format support (I believe this is what you referred to as the Introl format, a term I am new to), and while I haven't tested it much, a quick MS-DOS assembly Hello World with no libc compiled smoothly. The linker still needs support for archives, but using the code from my old prototype I think I can make it work eventually. After some testing, this would make the linker work as a drop-in replacement for ld86. As a nice side effect, it could also theoretically link ELF, as86 and OMF (implementation pending) object files together, since the linker doesn't care about the source file format type during the actual linking stage.

Compiling the linker as a 16-bit binary might be tricky, it uses 64-bit integers extensively, relies on C++20 specific features, and in general I have made design choices that are suboptimal with respect to runtime and memory requirements. My goal was to make the linker conceptually transparent and more of a tool to manipulate obsolete file formats, some of which are often lacking in documentation. Specifically, all binaries are fully parsed and loaded into memory, then converted into an internal module representation, all the modules are concatenated in memory and then converted into the target binary format. Had I targetted 8086 as the host, I would have designed it very differently (something I actually considered doing at some point, but decided I would rather focus on transparency and format support). It could still be interesting to give it a go and see how well it fares on an 8086, but I'm not very confident.

The original, unpublished prototype I wrote around a decade ago happens to have grown out of my frustrations with attempting to extend ld86 though, so I wonder if some of the ideas I had in this linker could be backported to it by introducing an "object format abstraction layer" (basically what I did here, except much more lightweight).

[BinaryMelodies]

As for the elksemu related topics, I think the following thigs can be done:

• Incorporating the new system calls (select, socket, bind, listen, accept, connect). Most of the implementations are just 16-bit versions of the standard Linux calls, except for select which only supports 32 file descriptors instead of the 1024 on my standard Linux. I believe I checked some header files in dev86 for this behavior, I think they should be compared to the current ELKS implementation, just in case.
• Supporting COMBID is easy enough, even if it is not used in ELKS anymore. I think it worked a bit like the tiny memory model under MS-DOS, having a single address space for both code and data, but I'm not sure and I would have to check.
• It might make sense to incorporate my changes with libx86emu for non-x86 platforms. I have not pushed those to github, since 16-bit protected mode support also ended my need for using that library.
• The old system call numbers and the old brk system call is apparently not needed. You're probably right about the reason being the old stack layout, the old brk call just checked that the new break value isn't in the middle of the stack, then ignored it and returned 0.
• The additions for the ELF format and MINIX system calls are probably not needed.
• If I get around to it, I might check out execve_os2 and see if I can incorporate that into elksemu. (It would also be exciting to make my linker generate OS/2 executables for ELKS, it already generates them for OS/2, Windows and Multitasking MS-DOS after all).

If that works for you, I could collect just those changes, place them in a separate branch and make a pull request. Note that only the first 2 points are readily available in the code base, the other points would be available at a later point in time.

Thank you again for reaching out and for the very interesting commentary! I can't respond to all of the other points right now, but it was interesting and informative! I am excited to see further progress on the ELKS project, and I hope some of this work will be usable for your tools! Let me know if you have any follow up or other things you would like to discuss.

[BinaryMelodies]

As of now, the linker can generate an ELKS binary using the bcc/as86 output of a Hello, World application, together with the dev86 standard libraries, see tests/others/bcc_example.c. There's definitely some improvements left to be done (and I was a bit confused by how ld86 treats imported/common symbols), but it shows that it does have the potential to be a drop-in replacement for ld86.

[ghaerr]

I added as86 object format support
it could also theoretically link ELF, as86 and OMF

Very cool! I hope to try it after getting it compiled. Are you familiar with Peter Anvin's 16-bit ELF variation used and implemented by TK Chia in the ia16-elf-gcc compiler (the one used by ELKS)? It uses a LMA != VMA scheme, and is also discussed a bit here. There are a number of new relocations that need to be handled and I don't think a standard "ELF" object file would work, as most ELF files are intended only 32- or 64-bit systems. Actually, now that I think about it, it might not matter to be able to link different object formats since the compilers themselves use different function calling conventions (ia16-elf-gcc on stack, OpenWatcom via register, and as86 only currently used by the new C86 toolchain passed on stack).

ia16-elf-gcc requires the elf2elks post processor which converts the linked ELF executable to ELKS a.out format, which supports 2 code segments (.text and .ftext) and one .data segment. At one point in getting the OpenWatcom C compiler working for ELKS, I wrote/ported an OMF to ELF object file converter and started down that path. It turned out to be a huge mess when the upstream compilers and assemblers started emitting directives that weren't compatible with each other and especially the ld-gold linker, items that were beyond just object format conversions.

Compiling the linker as a 16-bit binary might be tricky, it uses 64-bit integers extensively, relies on C++20 specific features, and in general I have made design choices that are suboptimal with respect to runtime and memory requirements.

Totally understand - after looking at the source, I don't believe it would run in 16-bit segmented architecture without large model, and that leaves us with an OpenWatcom port, for which I don't think C++20 has been implemented. Even then, given what I've learned porting our 8086 toolchain to ELKS, we're very short on memory and I've had to write a special "far arena" based malloc/realloc to produce allocations outside the default data segment and build the applications in large model. I haven't even tried to push ld86 to see when it runs out of memory just reading in the object files before laying out the first link pass all in the resident RAM working set.

attempting to extend ld86 though, so I wonder if some of the ideas I had in this linker could be backported to it by introducing an "object format abstraction layer"

Interesting idea, but probably not worth the effort, as I'm finding that the assembler and linker need to be pretty close to each other in terms of various compatibility items - .comm/common data and weak symbol support come to mind. (I noticed you added both to RetroLinker, nice! :) I'm trying to get OpenWatcom to add weak symbol support to the compiler, the wlink linker supports it. For now, since the ELKS C library has as few cool uses for it, I actually wrote an OMF object file post-processor that finds passed symbols and "weakens" them before passing the .obj files to wlink.

the linker can generate an ELKS binary using the bcc/as86 output of a Hello, World application, together with the dev86 standard libraries, see tests/others/bcc_example.c.

Are these a.out v0 binaries? Have they been tested on ELKS proper, or only elksemu? We don't produce v0 binaries anymore, but still load them. Also, the lkundrak dev86 you're using is quite old, I and ELKS have used an updated version here from which as86, ld86, ar86 and objdump86 were grabbed and then updated with more fixes and enhancements in the 8086-toolchain project.

If you'd like, I can post a fully-compiled ELKS C library libc86.a in as86 object/archive format which can be used to link executables using ld86 for ELKS using the full C library. I'm probably getting ahead of myself though since you're trying to build a multi-object format linker and I'm working on getting a C toolchain and C library running on host & 16-bits.

[ghaerr]

As for the elksemu related topics, I think the following thigs can be done (in summary most all the changes you've already made minus possibly sys_brk):

Thank you for thinking about this! I believe it would be worthwhile for ELKS, should you be able to find time to submit a PR for them individually or separately:

• New network systems calls and select
• Modified version of sys_brk, but not renamed or renumbered (i.e. no new syscalls.dat), if the existing elksemu sys_brk doesn't work. I can't run elksemu so I'm unsure of its actual suitability to run modern ELKS executables. brk should set the heap if its above the end of .bss and below the stack pointer, otherwise return -1. Here's the current implementation, there's quite a bit more error checking going on but essentially the same thing. Things are getting a bit more complicated with v1 executables because of the minstack header field, which allows for a "protected" stack area of which v0 executables know nothing about.
• Supporting COMBID. Agreed its implementation is pretty much code and data in a single segment - but ELKS won't likely implement this in the kernel. Add this if your tools require it for testing though.
• strace functionality
• Reboot code changes or anything else that has fallen behind, as elksemu is somewhat unmaintained at the moment.

I might check out execve_os2 and see if I can incorporate that into elksemu.

That would be VERY cool, as increasingly we're getting contributions, including the 8086-toolchain project, which require lots of memory and need the OpenWatcom compiler and OS/2 NE load format. I can help you with whatever you might need on that, except for actually running elksemu!

It might make sense to incorporate my changes with libx86emu for non-x86 platforms.

This also sounds very interesting, but potentially a big project. We would need to bring libx86emu into the ELKS repo and compile it - I'm not sure how big a job that is, but currently ELKS isn't set up for ./configure sort of things, much preferring simpler implementations.

Thank you for your comments! I've been a bit busy traveling and haven't had the time to respond as I normally do.

[BinaryMelodies]

Are you familiar with Peter Anvin's 16-bit ELF variation used and implemented by TK Chia in the ia16-elf-gcc compiler (the one used by ELKS)? It uses a LMA != VMA scheme, and is also discussed a bit here. There are a number of new relocations that need to be handled and I don't think a standard "ELF" object file would work, as most ELF files are intended only 32- or 64-bit systems.

I am aware of them, elf.h even has constants for them, but since none of my tools that I currently use generate ELF files using them, I haven't implemented them yet.

Actually, now that I think about it, it might not matter to be able to link different object formats since the compilers themselves use different function calling conventions (ia16-elf-gcc on stack, OpenWatcom via register, and as86 only currently used by the new C86 toolchain passed on stack).

Yes, that would be an issue. Combining different object formats is more of a theoretical possibility. I actually expect there to be conflicts for the expectations regarding memory layout between different linkers which might make interaction between different object formats dead in its track.

For now, since the ELKS C library has as few cool uses for it, I actually wrote an OMF object file post-processor that finds passed symbols and "weakens" them before passing the .obj files to wlink.

That's cool! I learn more about the linking process and feature set as I go, and I've used the sources for ld86 to understand how it deals with weak symbols. For example, I reailzed yesterday that ld86 seems to treat imported symbols whose segment number isn't 15 as weak common symbols, and my support for this in RetroLinker is incomplete right now.

Are these a.out v0 binaries?

Yes, I haven't implemented support for v1 binaries yet. I would probably want to have a more up-to-date dev86 toolkit to have some reference to compare the output to.

Have they been tested on ELKS proper, or only elksemu?

Unfortunately I have never used ELKS proper before, though it would be very interesting to see it in action!

We don't produce v0 binaries anymore, but still load them. Also, the lkundrak dev86 you're using is quite old, I and ELKS have used an updated version here from which as86, ld86, ar86 and objdump86 were grabbed and then updated with more fixes and enhancements in the 8086-toolchain project.

If you'd like, I can post a fully-compiled ELKS C library libc86.a in as86 object/archive format which can be used to link executables using ld86 for ELKS using the full C library.

That would be fantastic! I am currently using the tools provided by my Linux repositories, which seem to be quite old.

I'm probably getting ahead of myself though since you're trying to build a multi-object format linker and I'm working on getting a C toolchain and C library running on host & 16-bits.

While the goals and scopes we have in mind are somewhat different, I do want to see RetroLinker have some possible production uses. Also this project did grow out from my attempt to extend ld86 around a decade ago, so I still want to put in some work to see if using it for modern ELKS could work out.

[BinaryMelodies]

* New network systems calls and select

That can be done easily. I will use the new numbering for them.

* Modified version of sys_brk, but not renamed or renumbered (i.e. no new syscalls.dat), if the existing elksemu sys_brk doesn't work. I can't run elksemu so I'm unsure of its actual suitability to run modern ELKS executables. `brk` should set the heap if its above the end of .bss and below the stack pointer, otherwise return -1. [Here's the current implementation](https://github.com/ghaerr/elks/blob/master/elks/arch/i86/mm/malloc.c#L268), there's quite a bit more error checking going on but essentially the same thing. Things are getting a bit more complicated with v1 executables because of the `minstack` header field, which allows for a "protected" stack area of which v0 executables know nothing about.

As I've only been running binaries compiled with a very old version of dev86, I am not sure that would actually be beneficial for elksemu. I would need to try out a more up-to-date toolkit first and see how it handles brk. Since the modified version of sys_brk is actually reverting to an older behavior, it's probably not needed for modern ELKS.

* Supporting COMBID. Agreed its implementation is pretty much code and data in a single segment - but ELKS won't likely implement this in the kernel. Add this if your tools require it for testing though.

Simple enough. I could make compilation optional or issue a warning that COMBID binaries aren't supported on ELKS anymore.

* strace functionality

I forgot I added that, thank you for mentioning it!

* Reboot code changes or anything else that has fallen behind, as elksemu is somewhat unmaintained at the moment.

Alright.

I might check out execve_os2 and see if I can incorporate that into elksemu.

That would be VERY cool, as increasingly we're getting contributions, including the 8086-toolchain project, which require lots of memory and need the OpenWatcom compiler and OS/2 NE load format. I can help you with whatever you might need on that, except for actually running elksemu!

Thank you! It will be a slightly bigger undertaking, of course.

It might make sense to incorporate my changes with libx86emu for non-x86 platforms.

This also sounds very interesting, but potentially a big project.

I have done this for an earlier version of elksemu, so the code is written, it just needs to be incorporated into the newer version of elksemu. One issue is that accessing the x86 registers from C is different for libx86emu and for a 16-bit protected task, which might require rewriting a lot of the code to support macros (I don't actually remember how involved this actually was, just letting you know the impact this could have on the codebase).

We would need to bring libx86emu into the ELKS repo and compile it - I'm not sure how big a job that is, but currently ELKS isn't set up for ./configure sort of things, much preferring simpler implementations.

Short of ./configure, I suppose there could be a flag in Makefile that switches between compiling to run the binaries in 16-bit protected mode or via emulation.

Thank you for your comments! I've been a bit busy traveling and haven't had the time to respond as I normally do.

No worries, thank you for your responses!

[ghaerr]

That would be fantastic! I am currently using the tools provided by my Linux repositories

Here's the most recent ELKS C library compiled by the 8086 toolchain into AS86 object and AR86 archive format:
libc86.a.zip

I've used the sources for ld86 to understand how it deals with weak symbols. For example, I reailzed yesterday that ld86 seems to treat imported symbols whose segment number isn't 15 as weak common symbols,

I didn't realize ld86 supports weak symbols!? What is a "weak" common symbol? I thought the rule is that if a symbol is marked common, then it is linked if either 1) it is referenced (this is the otherwise definition of weak but always the case for common, right?), or 2) a separate, non-common definition is seen, in which case the common definition is discarded. Otherwise, the common symbol is not linked in.

I could make compilation optional or issue a warning that COMBID binaries aren't supported on ELKS anymore.

We probably don't need a warning or option for this, just leave it as you have it.

[BinaryMelodies]

That would be fantastic! I am currently using the tools provided by my Linux repositories

Here's the most recent ELKS C library compiled by the 8086 toolchain into AS86 object and AR86 archive format: libc86.a.zip

Thank you!

I've used the sources for ld86 to understand how it deals with weak symbols. For example, I reailzed yesterday that ld86 seems to treat imported symbols whose segment number isn't 15 as weak common symbols,

I didn't realize ld86 supports weak symbols!? What is a "weak" common symbol? I thought the rule is that if a symbol is marked common, then it is linked if either 1) it is referenced (this is the otherwise definition of weak but always the case for common, right?), or 2) a separate, non-common definition is seen, in which case the common definition is discarded. Otherwise, the common symbol is not linked in.

My bad, what I meant to write is that common symbols behave like weak symbols in that if another definition appears, the common one can be discarded. My point was moreso that imported symbols with segment number 15 are undefined, whereas imported symbols with segment number not 15 get treated as common symbols. At least that was my impression from the source code of the old linker.

[BinaryMelodies]

I just pushed a commit for a prototype elksemu update that lets you switch between using the new ptrace based method to execute binaries in 16-bit protected mode and using libx86emu, at compilation time. I also reincorporated and updated the vm86 method from the older version of elksemu, in case there are x86-32 Linux users who want to use that.

It can probably use a bit more polish, but I wanted to show what the extent of changes would be like.