OSDev.org

elderK wrote:Yeah, its so totally worth not worrying about - Ill just waste MORE memory in some way.
Phft. Shame on you.

ROI. Availability of documentation, availability of tools, speed of implementation. Sometimes you waste memory to speed up things, sometimes you waste clock cycles to save space.

elderK wrote:As for ELFs, no, you dont necessarily have to lose out on a single register.
It depends if it is full PIC code, or simply relocatable code and target architecture.

elderK wrote:Where as ELF can go ANYWHERE, without precalculation.

If it is fully position independent, you need to keep around the addresses of two tables, as I understand. So you lose a register. However, if it is not position independent, then you need relocations, be it ELF or PE file format, and once relocated, code cannot be shared between processes.

elderK wrote: 512Bytes isnt a big thing to get upset about?
MY I REMIND YOU THAT 512B can BOOT the freaking machine?

Wow, I wonder why we need the BIOS, why lots of people need a second stage boot loader. A simple boot sector can boot the entire machine (including the OS), right? And by the way, it only occupies space on the disk. You don't need to keep the headers around, once the image is loaded.

elderK wrote: As for the REBASE tool, good for you.
THe point is that you must precalculate the base - before use. Otherwise, the OS has to modify it, which makes the text unable to be shared, read the MS Spec and see for yourself.

That is correct, however system DLLs are loaded first into the address space of a process, making any collisions (and relocations) highly unlikely. It is still possible, though, that some libraries loaded later on, need relocation.

Why all the worry about load time? Continually loading executables isn't going to be efficient anyway - better to load once and do everything you need to in one go. Isn't it more important how efficient the code is once it is loaded? While I see flexibility in the ELF GOT and PLT doesn't that add to memory overhead in terms of both memory allocated (RAM resource usage) and accessed when making library calls (CPU cache resource usage)?

I appreciate my understanding is limited. Why would rebasing a runtime be needed for PE if you are using system dlls, wouldn't they already be carefully specified at different bases to prevent this from being needed?

This thread is two years ago...

About GOT and PLT, elf provide an option to group relocatable items together, such that a minimal region of memory is needed to be CoW and almost all memory can be shared among processes with different address layout. This indeed reduce memory and cache stress upon share. The trade off is one indirect access.

By the way, this is just one option provided by ELF, you can still use inline relocation.

I read up on wikipedia and corrected my understanding somewhat. Both ELF and PE make indirect jumps to enter a library function via table of function addresses generated at runtime. It is the absolute jumps within the code itself that may need rebasing in PE and in ELF also uses indirect jumps for these via a table.

I suppose cant really answer poll without some empirical data of the real world to compare the negative effects of both options.

I don't think any of the options are valid; if there is a speed difference between parsing a PE and an ELF container, it is entirely negligible compared to the runtime of the program (most likely). Also, once the binary is expanded into memory, I'm failing to see why the memory usage of a PE or an ELF binary would be different; the metadata doesn't need to be stored in memory, after all.

I use PE simply because it is what my toolkit puts out (MSVC). I could convert it to ELF, but I know PE format better than I know ELF, and I wouldn't gain anything by doing such. If anything, I will strip out some MS-specific stuff from PE and make a custom PE format.

ui486 wrote:Why all the worry about load time? Continually loading executables isn't going to be efficient anyway

You're wrong, loading only executables that and when they needed and share afterwards, that's efficient. Sparse load is always better than huge pikes.

- better to load once and do everything you need to in one go. Isn't it more important how efficient the code is once it is loaded?

No. Your argument fail, just take a look at any android phone. After turned on, it jit compiles (muhaha) the dalvik code and caches everything it can. Result: you cannot use the phone for minutes (!) after turned on, and you have to kill some annoying tasks (if you don't want the battery die by the evening) for another minutes.

Loading only what's needed (and do jit compile at appropriate time) results in few secs of boottime and low energy requirements. For example give a try to win8.
Much better user experience, don't you think?

While I see flexibility in the ELF GOT and PLT doesn't that add to memory overhead in terms of both memory allocated (RAM resource usage) and accessed when making library calls (CPU cache resource usage)?

I appreciate my understanding is limited. Why would rebasing a runtime be needed for PE if you are using system dlls, wouldn't they already be carefully specified at different bases to prevent this from being needed?

Let me put it this way: the representation of a data on storage is irrelevant. You can store PIC code even in a.out format (it's quite uncommon, but possible). If you don't know enough theory about processes and library calls, and how they related to the information stored on storage, you have no chance. If you can do a clear and comprehensive design, there are no limits. You can create your own object file if you like.

I never thought speed or size was something that you would consider if you're going to use ELF or PE. I used ELF because it is well documented and the ELF compiler support. When it comes to size I don't think it matter much because there are several options that you can choose in order to reduce the size. For speed there is an option to align the code and data so that it fits the block size of the file system, this might make demand paging quicker however this increases the size of course.

Not answering the poll since it's over simplified and most likely one of these silly questions simply asked because the OP knows it will cause a linux vs windows proxy flame war (;

That said i've written loaders for both PE and elf, if you're talking about executables only the actual process of loading a program is virtually identical aside from skipping over the MS-DOS stub. I've found specifications for each easy to find, follow and implement and don't really see what the big deal is. Perhaps because i've programmed on a wide range of different CPU architectures and operating systems.

That said the inability of the C compilers typically associated with PE .exe's (eg MSVC, watcom, etc) to generate position independent code tends to make the implementation of shared libraries more complicated. I'm having problems with this at present as i'm porting a microkernel type project from ARM to x86. I originally used MSVC's ARMV5 compiler so the PE .exe format was used for the kernel and the .dll format for servers which are dynamic linked into the kernel address space though run in user mode and do not have access to kernel data structures. The lack of PC-relative memory access instructions on the x86 means this kernel "plugin" type architecture no longer works as intended. It's likely i'll be migrating to gcc for it's -fpic option and re-writing the boot loader to handle the ELF file format.

Brendan wrote:Hi,

Jeko wrote:Which are pros and cons of PE and ELF file formats when they are used for executables, shared libraries and device drivers?

PE: Designed by Microsoft for Windows. Really useful for executable files on Windows clones.

ELF: Designed by SCO for Unix System V. Really useful for executable files on Unix clones.

BCOS_NFF: Being designed by me for my OS. Really useful for all native (for my OS) file types including (but not limited to) executable files for my OS. Consists of a generic header (file size, magic number, checksum/CRC, file type ID) that is identical for all native file types, optionally followed by an extended header that depends on the file type ID in the generic header.


Cheers,

Brendan

Are you going to write your own compiler for BCOS_NFF?

Hi,

BMW wrote:

Brendan wrote:PE: Designed by Microsoft for Windows. Really useful for executable files on Windows clones.

ELF: Designed by SCO for Unix System V. Really useful for executable files on Unix clones.

BCOS_NFF: Being designed by me for my OS. Really useful for all native (for my OS) file types including (but not limited to) executable files for my OS. Consists of a generic header (file size, magic number, checksum/CRC, file type ID) that is identical for all native file types, optionally followed by an extended header that depends on the file type ID in the generic header.

Are you going to write your own compiler for BCOS_NFF?

I am planning to write my own toolchain eventually, but not because of my file format.

My native file format/s are simple enough that it's easy to (for e.g.) use NASM to generate a flat binary where the header/s are created by macros. If I wanted to use C I'm sure I could do something similar (with a linker script and some assembly that creates the header for a flat binary), and I have done it like this in the past.


Cheers,

Brendan