flat assembler
Message board for the users of flat assembler.

Index > Main > ELF Object Portability

Author
Thread Post new topic Reply to topic
Imagist



Joined: 13 Jun 2004
Posts: 114
Location: Pennsylvania (USA)
Imagist
I'm creating an interpreter for a new programming language, and one of my main goals is portability.

The main download page says this about the FASM package for Unix/libc:

Quote:
This is version for all platforms that have support for the ELF object format and the C library, like OpenBSD or Zeta. The object file provided in this package can be linked with the C library to create the final executable for any such system. The documentation in pure ASCII format is included.


Does this mean that you can compile an FASM program to an object file (traditionally tagged filename.o) which can be linked by (for example) GCC?

In other words, could the same FASM code be used to create an object file that would successfully link on Windows, Mac OS X, and Linux? These are my three initial target platforms.
Post 11 Dec 2008, 19:16
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
GCC can handle ELF, and i think it compiles for all three (but never tried it with Mac OS X). But implementation of libc can differ a bit, you might still need some tiny libc wrapper in some cases.
Post 11 Dec 2008, 19:41
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
asmcoder



Joined: 02 Jun 2008
Posts: 784
asmcoder
[content deleted]


Last edited by asmcoder on 14 Aug 2009, 14:54; edited 1 time in total
Post 11 Dec 2008, 20:11
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Quote:
what is linking?
Almost every compiler (except FASM, NASM and YASM) builds executables in two steps. First step is to build object file (there are various formats, mostly MS-COFF on windows and ELF on linux). Object files are intermediates, where code is compiled, but absolute addresses are not yet set. Second step is linking (with "linker"), which can link several such objects together, relocate addresses to final values, and build the final executable.

Main advantage of this approach is that it allows you to break your source into several modules (object files), so you don't have to always recompile everything, only the module you changed. You'd see this advantage if you would made some bigger project. Of course, there are other advantages.

Quote:
why u want use gcc to recompile fasm files? gcc != fasm

I suggested using GCC just for linking, not compiling. You compile code to ELF object in FASM, and then link it to different executables for various OSes, using GCC.
Post 11 Dec 2008, 22:43
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
mattst88



Joined: 12 May 2006
Posts: 260
Location: South Carolina
mattst88
Imagist wrote:
IDoes this mean that you can compile an FASM program to an object file (traditionally tagged filename.o) which can be linked by (for example) GCC?


Yes, absolutely.

Code:
fasm code.asm # creates code.o
gcc code.o -o code    

_________________
My x86 Instruction Reference -- includes SSE, SSE2, SSE3, SSSE3, SSE4 instructions.
Assembly Programmer's Journal
Post 11 Dec 2008, 22:54
View user's profile Send private message Visit poster's website Reply with quote
asmcoder



Joined: 02 Jun 2008
Posts: 784
asmcoder
[content deleted]


Last edited by asmcoder on 14 Aug 2009, 14:54; edited 1 time in total
Post 11 Dec 2008, 23:12
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
When you want to write portable ELF file, you must use interface that is present on all OSes. Of course 0x80 isn't. Such interface is libc - Standard C Library. That is present everywhere, with quite minor differences (but still there are some).

Anyway, using same ELF file to build for different OSes is *not* what it was intended for, and it only works to some extent, because existing implementations of C library are pretty similar at binary level. (C library is only defined on C source code level, and can be implemented in any way on binary level)

So - you don't use int 0x80. You use libc. For example you declare "printf" as external symbol, and then "call printf". Linker will relocate the address to actual address of actual printf function. For practical example of using libc, get libc version of FASM and study system.inc, for example.

Quote:
whats diffrent between object file and executable file?

object file references all stuff through names, not addresses. For example if you have "mov [var123], 100", object file doesn't generate any address. In object file you only have information that this instruction refers to symbol named "var123". This symbol can lie in same object file, or in another object file. During linking, all objects are pasted together, and address in this instruction is overwritten by actual address (RVA actually) of symbol "var123".

Also every object can have various sections, usually data and code. When linking, all data sections are merged into one big data section, and all code sections are merged into one big code sections. This is still one of problems of FASMers who use direct compilation to .EXE, but want to divide source into modules: they have to wrap data definitions in macros like "idata", to have them all collected in one place.
Post 12 Dec 2008, 00:35
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
asmcoder



Joined: 02 Jun 2008
Posts: 784
asmcoder
[content deleted]


Last edited by asmcoder on 14 Aug 2009, 14:54; edited 1 time in total
Post 12 Dec 2008, 11:17
View user's profile Send private message Reply with quote
dosin



Joined: 24 Aug 2007
Posts: 337
dosin
Quote:
why bother with it?


I would think this would answer it:
Quote:
Everyone could then edit it to fit system library


This can run into problems... end up with multible versions - run into compatibility problems ... ect..


Quote:
Edit imports, header, and perhaps minor code

The user can still do this? but create there own funtions.. Then the OS Devel.. has the options to add to the lib or leave it out.. if not the os devel has no control over what is added or removed...

even in C you can create your own printf if you dont want to use the one provided..
Post 12 Dec 2008, 12:36
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Quote:
i understand the idea, but... why bother with it?

1. You don't need to always recompile every entire code for executable, just the changed part. This saves considerable amount of time on useless recompilation.
2. You can distribute static libraries (eg. not dynamic, in separate file, like DLLs) without giving away their code, and/or without need for people to study and always recompile their code.
3. It offers good and time-tested platform for breaking code into multiple more/less independent modules, unlike using FASM to compile directly to executable.
4. It allows you to mix code from various languages into same executable. Priceless if you want to use library written in other language than the one you are using.

Quote:
wouldnt be simplier to just write source code in fasm with proper headers (format pe/format elf)? Everyone could then edit it to fit system library. Edit imports, header, and perhaps minor code.

In that case, "editing" would be a stupid way to do it, more sane would be way used by FASM for example. But anyway, that only solves one point - OS portability (original topic of this thread), which object files aren't even supposed to solve. Main reason for using object files is what i have written up.
Post 12 Dec 2008, 13:53
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Imagist



Joined: 13 Jun 2004
Posts: 114
Location: Pennsylvania (USA)
Imagist
Vid, what would you suggest as the best way to write cross-platform FASM?

_________________
Many things are possible. Few things are likely.
Post 16 Dec 2008, 21:28
View user's profile Send private message Visit poster's website Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
Imagist,

Define "platform".

Common ground for every x86-32/64 linker in existence? Wink
Post 16 Dec 2008, 22:48
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Quote:
Vid, what would you suggest as the best way to write cross-platform FASM?

Depens... but generaly speaking, it would be:

- Platform-specific "bottom" layer to wrap system functions to interface common for all platforms
- Platform-specific top-level file (the one you compile, with "format" definitions etc)
- Rest can be portable, included from all top-level files. This code can only call OS through the wrapper functions.

This is a way that FASM itself uses too, btw
Post 17 Dec 2008, 02:16
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.