What is your MyCard?The New World OrderWho wants to be on the Advertising Team?


Computer Help & Chat

Get help with computer-related problems, or just chat about hardware, software, emulation, programming, networking, smartphones/tablets or pretty much any other computer topic.
Mixing programming languages with gcc/clang
Posted: Posted October 12th by Kohlrak

Just for fun, and to fulfill my random desire for a short ego trip, I want to address how one would go about mixing programming langauges using GCC or CLANG toolchain. The objective of this is to mix compiled languages into one executable, as opposed to mixing progams made in separate languages, or mixing compiled programs with interpreted languages. The reasoning and logic on how this works will be demonstrated directly below, but practical examples will also be made available following that section.

Logic/Reasoning:

In compiled langauges (including java), all code is converted (as major stages, not minor stages) from it's initial "language" to assembly (human readable machin code). The various assembly outputs are then converted to "object files" which are intermediate files between assembly and binary (not necessary for all programs, but when mixing it's absolutely necessary). The format for these "object files" varies from compiler to compiler, but the general idea is to have everything pre-compiled with references to instructions that may need to be modified to reflect changes in the final binary (memory references to code and data, for the most part). These references are recognized as "symbols" which, due to history, are basically C-compatible. Object oriented languages will need their symbol names "mangled" so that things like operator overflowing end up with c-compatible names.

So, what you want to do is get the compiler to make object files and auto-detect the programming language being used. Normally, it does this based on the file extension of the input files. .c for C, .cpp for C++, .S for assembly (not sure why, though it uses .s for assembly output), etc. The linker will automatically be run afterwards, and will take the object files (which, at this point, are independent of programming language) and make the final binary out of them.

Example (x86, 32bit): Beware, the ASM syntax on pastebin doesn't love you (more to do with the wonky way GAS works [specifically the comments]).

makefile: https://pastebin.com/EmMEaMwt
main.cpp: https://pastebin.com/gdsXsTmB
asm.S: https://pastebin.com/xwUdSQx1

Example (ARM: armeabi-v7a): This is my Samsung Galaxy Tab E (using Termux), but should work on just about any android that's running ARM.

To be honest, I don't fully understand cargo.inc. There might be some extra formatting that's not necessary in there, but I made it a file from some boiler-plate code found using the -S option. It is basically just necessary to describe your target processor to clang/gcc so it knows what encoding to use and what to tell you if you try using an instruction that doesn't exist. All the assembly does here is return 0, but that should be more than enough for you if you use what's above for x86 and extrapolate upon it.

makefile: https://pastebin.com/wqQd5JQJ
main.cpp: https://pastebin.com/PDXXZTT9
cargo.inc: https://pastebin.com/Jq4yBNuQ
asm.S: https://pastebin.com/6XXG71d4

settingsOptions
There are 9 Replies

So if I'm understanding this correctly, what you're doing is taking two programs written in completely different languages, and combining them together during the step where they're assembly language?

Posted October 12th by Xhin
Xhin
 

No, when they're object files. In theory, you could do it when they're assembly, but that results in copy-and-paste. I will agree that the padding and executable expansion that results from having so many separate object files merged is horrendous, but that's the price of using a linker to begin with (which you're going to use if you're not using assembly or an interpreted language).

Posted October 12th by Kohlrak
Kohlrak

What's the difference between object files and assembly code?

Posted October 12th by Xhin
Xhin
 

Assembly is the last step that's human readable. Object files (format varies per compiler) are mostly pre-assembled assembly. I would argue that the object file stage is unnecessary, but that's probably to cut down on memory usage during assembly stage, since a huge assembly source file would probably eat alot of RAM (does in my unfinished assembler).

Posted October 12th by Kohlrak
Kohlrak

Well in that case what's the difference between object files and binary?

Edited October 12th by Xhin
Xhin
 

Also I do know that the actual binary varies depending on the processor's specific sets of instructions.

Posted October 12th by Xhin
Xhin
 

Well in that case what's the difference between object files and binary?


Well, object files usually don't have the symbols completely resolved, thus the call and jmp instructions aren't finalized. Their addresses are still relative. Moreover, there's alot of overhead in object files that don't make it into the end binary (namely, the static symbols).

Also I do know that the actual binary varies depending on the processor's specific sets of instructions.


Assembly, object (linker) file, and binary all do. Often times the higher code does, too, even though the point of using anything higher than assembly is portability. In reality, that portability is rarely achieved.

Posted October 12th by Kohlrak
Kohlrak

Assembly, object (linker) file, and binary all do.

Yeah but not in the same way. Assembly at least *looks* the same between different variations, whereas JMP or RET can translate to totally different binary codes depending on the processor.



Posted October 12th by Xhin
Xhin
 

Well, yeah, Potato potato, tomato tomato. Theory vs practice is the real issue.

Posted October 12th by Kohlrak
Kohlrak
Reply to: Mixing programming languages with gcc/clang

Enter your message here


Site Rules | Complaints Process | Register Complaint Facebook Page
GTX0 © 2009-2017 Xhin GameTalk © 1999-2008 lives on