Undefined symbol 'imod' when linking using ld86

[pranavappu007]

Okay, I'm trying to compile some C code using bcc(ANSI mode) for 8086 target. I also use some good old nasm assembly, so I have to link using ld86. I tried to do a modulo operation(%) in C as a part of a simple function, and then the linker start giving me this error: "undefined symbol: imod". I can see the C compiler apparently compiled modulo operation as '"imod" instead of dividing and then getting the remainder.

My question is how to fix this? Also, who is wrong here? Compiler, or linker, or me? I couldn't find anything online, so this post is my last chance. I can't continue without modulus. If this didn't work, I think I'll have to write an assembly routine just for doing modulo.

[h0bby1]

Thats probably due to compiler runtime, there are various things you can do to avoid this like tweaking optimisation setting, intrinsec function, or eventually writting your own function in nasm and calling it explicitly instead of doing the division.

It can happen if you try 64 bits division on 32 bits instructions set, for example.

Those can often be hard to spot as well as the conditions tjat will lead the compiler to generate the call instead of using inline assembler.

The best way is to know your compiler inner working and making explicit call to your own asm runtime routines explicitly where you know the compiler might generate these.

Or check the source code of the compiler runtime if you have it to include the function in the build.

Or link with compiler runtime library.

But each compiler might have their own set of similar function and conditions for using them.

Maybe try speed optimisation instead of size for example as those function call will typically yield smaller/slower code.

[nexos]

Does BCC have a compiler runtime library (like libgcc of compiler-rt)? You may need to link with that. Also, try narrowing down the code that triggers this error.

[Octocontrabass]

BCC has a runtime library, much like how GCC has libgcc and LLVM has compiler-rt. You must link the runtime library.

BCC has several runtime libraries. You'll have to choose the appropriate one according to the -M option you pass to BCC.

[nexos]

Thanks, Octocontrabass. I don't have a lot of experience with BCC

[pranavappu007]

I did narrow down the error and thus found it happens whenever I use a modulus operator. In this specific case, it happened when I did `var%10`. I don't know if any other code might have affected this. Also, Isn't BCC's default linker is ld86?

[Octocontrabass]

Also, Isn't BCC's default linker is ld86?

Yes, but LD86 doesn't know anything about BCC's runtime libraries. When BCC invokes LD86 to link a binary, BCC has to tell LD86 to include the runtime library.

[pranavappu007]

Yes, but LD86 doesn't know anything about BCC's runtime libraries. When BCC invokes LD86 to link a binary, BCC has to tell LD86 to include the runtime library.

But do I need the runtime library? I m using it like a standalone code, no environment. Also, how can using modulo operator needs runtime libraries?

(Right now, I changed it to an explicit assembly routine and it works. So I am 100% certain that it is indeed, the modulo operator. And 'imod' sounds like mimicking an instruction..)

[Octocontrabass]

But do I need the runtime library?

You need a runtime library. BCC generates code that will call the runtime library, even in a freestanding environment. It's usually best to use one of the libraries provided by BCC, but it's possible to write your own runtime library if you know exactly what its functions are supposed to do. (BCC's runtime library is a lot simpler than libgcc!)

Also, how can using modulo operator needs runtime libraries?

That sounds like a question for the BCC developers.

[nullplan]

But do I need the runtime library? I m using it like a standalone code, no environment.

If your compiler emits a call to a runtime library, then you either need the library, or you need an implementation of the called function(s) suitable to your needs. Standalone does not mean your compiler gains magical abilities, and it is still beneficial to outsource complicated things into a library.

Also, how can using modulo operator needs runtime libraries?

Because your CPU does not have the instructions needed for the job. lmod sounds to me like it is trying to divide a long number, possibly by a short one. C has the semantics that dividing a 64-bit number by a 32-bit number should return a 64-bit number, and also dividing two 64-bit numbers should return a 64-bit number. But in 32-bit mode, x86 only has instructions for dividing a 64-bit number by a 32-bit number, with the result to be contained in a 32-bit number, and if the result doesn't fit, a #DE is issued. You don't usually want that. So the compiler writers created a function called lmod that implements the division in different terms, probably as shifts and subtractions, and so the #DE is avoided and you actually get the correct result.

I am only guessing based on the name, though. From what little I've looked up, the above might still hold up, but you have to divide all numbers by two.

[nexos]

Also, BCC's runtime library I'm quite sure has no dependencies, so you link it in and thats it