Isn?t Microsoft COFF PE format an ELF?
Are there many differences with the 'standard' elf?
(Tomasz, I ask here because I know you are working on it now, after the recent coffee version of fasm)
Tnx.
Posted on 2002-09-03 13:11:11 by slop
COFF is not ELF. Neither is Microsoft's modified COFF/PE.

Historically, COFF was used before SysV moved to ELF. If you want to learn about ELF itself, you may find it useful. That document is frequently referred as the prime source of ELF information. However, if you are not using any Unix or pseudo-unix, you don't want to look at it. :)
Posted on 2002-09-03 23:56:29 by Starless
Okay starless,

I tryed *it*, and it pointed to http://stage.caldera.com/developer/devspecs/gabi41.pdf
but the link seems to be broken.

My main question is:
if cOFF is not ELF, then what is it?
tnx

EDIT:Okay, now I got the file, the link is OK.
Thanks satrless. (Btw, what song is that bible...?)
Posted on 2002-09-05 08:09:25 by slop
Glad to be of help. :)

And, since we are talking about x86 here, here is another file which addresses x86 specific implementation. If you have some experience with AT&T syntax, it is a good starting point.

Assuming that ELF is used only on Unix or unix-wanna-be OSes, a tricky part (at least, to me) is to support the dynamic linkage information. (To be precise, position-independent code information.) ELF itself is quite clear about it, but an assembler needs to have a way to do it. For example, NASM has it implemented in its syntax in a pretty horrible way.

If FASM will ever support a true ELF (not an ELF wrapper around COFF), I would suggest that the dynimic linkage related part be implemented just like the segment override in the 16-bit mode. For example,


; get the current position in ebx using _GLOBAL_OFFSET_TABLE_
; and use ebx as the offset pointer
mov eax,GOT:global_var[ebx]
call PLT:malloc
mov GOTOFF:PIC_local_var[ebx],eax

Well, that's just my opinion.

===
BTW, sloppy, you seem to know King Crimson, right?
'Starless' is found in 'Red', and before 'Red', they released an album titled 'Starless ... and Bible Black'. I meant to upload another album cover as my avatar, but I've been too lazy. :)
Posted on 2002-09-06 05:42:31 by Starless
Thanks,
this new doc was a lot of help.
Yes I know KC, my brother keeps all day liustening to it... and you know, my brother and I don?t get on very weel.
Do you know of any other executable portable formats?
Like PE COFF --> windozs
ELF ---> UNIX
...?

Have they ever thought about making a standard that can run in ANY machine?

ANd how about new 64-bit architectures (any flavour RISC, CISC, VFMR...)?
What format do you think they'll use?
They'll create even ANOTHER format?
Or reuse ELf?
(Because in the first doc you gave me it said ONLY 32-bit, chapter 4)

(I'll ask my brother if he has a .bmp of an album cober to send you)
Posted on 2002-09-10 07:56:44 by slop
I have some very good ELF references and technical papers at home.... if I dont forget it, I'll post it later ;)
Posted on 2002-09-10 08:18:15 by bazik
Do you know of any other executable portable formats?
Like PE COFF --> windozs
ELF ---> UNIX
...?

Well, the word 'portable' is a bit misleading, because, IMO, having a same file format does not mean that a binary for one OS can be copied over another OS and run without any problem. And I personally think that using the word 'portable' is a sort of hype (as in Microsoft Portable Executable format).

And, for a different file format, there are several OSes which still use one of obsolete executable formats. But, unless you are trying to build a big fat library of executable file manipulation, I would say, you don't need to worry about other formats. (Or, you have to support some ages-old machines like old SGI with old IRIX...)


Have they ever thought about making a standard that can run in ANY machine?


I once heard of someone's idea about using the multiple section in a COFF or ELF file to contain different machine codes and select the right section at the run time - i.e. the OS kernel handles it. Not a bad idea if we have only handful of architectures and if we have huge disk space. But, for now, that would not be feasible. Suppose that you create a small application which runs on x86, alpha, mips (various versions), m68x00, power pc, sparc, ... How large would your binary be? :)

Besides, as mentioned earlier, a binary file is closely tied to the target OS. To give you an idea, Linux and FreeBSD have ELF as their primary binary format. Then, can I copy a FreeBSD binary to a Linux machine and run it without any modification? No. Each OS has its own set of system calls, and that is the source of the problem. So, to implement the idea of multiple sections, we need to add multiple OS sections even though the supported hardware is only one.

What if I copy a object file, not a final executable? Then, I might be able to link the object file with other native object files, as long as the migrated object file does not call any system functions. I tried moving Linux ELF object file to my FreeBSD machine and linking it. It happened to work. But, in general, I don't think it will work without a problem.


ANd how about new 64-bit architectures (any flavour RISC, CISC, VFMR...)?
What format do you think they'll use?
They'll create even ANOTHER format?
Or reuse ELf?
(Because in the first doc you gave me it said ONLY 32-bit, chapter 4)

Actually, there is an extension of ELF to 64 bit architectures, which Solaris on Sparc and Linux on Alpha use. I myself did not find any 'standard' document about 64 bit ELF and do not know much about it. Only thing I can say is that some of the existing 64 bit architecture with fairly new Unix implementation (either SysV or BSD) use ELF. Let's wait until bazik posts and see if that includes 64 bit ELF information. :)

<edit>
If you could find a 'Larks' Tongues in Aspic' image of right size, I would like to have a copy. :)
</edit>
Posted on 2002-09-10 19:27:20 by Starless
Hi Starless,

I'm also waiting that pengu melts his docs here ;)
what I meant for a 'standard' was something like a STANDARD obj file, like an abstraction that could be used in *ANY* architecture ever invented and the future ones.
That would be great, then the kernel (every different kernel, running in a different machine) would translate the common thing to its own machine code.

That would be fantastic.
That's my idea.

Btw, I got this from my brother's music directory (don?t tell him ;) ):
Posted on 2002-09-12 10:54:17 by slop