I realize this is only addressing part of this (and one of those parts was probably meant sarcastically, at that), but I will need to do more research before replying further. For now:
zaval wrote:Ok. How do I produce a DLL-like library with ELF? not PIC. What excatly ELF should I choose? "executable"?
Uhm, I would think setting the file header field
e_type to
ET_DYN (0x03) would be what you want, but you seem to think that this mandates PIC. AFAIK, that's not actually the case, at least not in the format (it can't be, because not all of the systems the format is used with can have PIC at all, as I mentioned).
I am pretty sure that to get GCC to produce a non-PIC object file just requires... not using
-fPIC. Oh, and using a cross-compiler rather than the default compiler, if you are on a system such as Linaro where the default for shared/dynamic libraries is PIC (you can disable that default by switches, but the whole point of a cross-compiler is that you bake that sort of thing into the toolchain rather than having to have spread across all your makefiles/project files and cluttering up the linker scripts). Am I missing something here?
You seem to be confusing 'how the software I am currently using is configured' with 'the hard limits of the file format'. Those limits are only there because you are using that specific distro's default setup.
I am also blanking on just why you don't want position-independent code - I am pretty sure you explained it at some point, but I will need to re-read your earlier posts. I probably should have been paying closer attention, and if so I apologize.
zaval wrote:yes, masturbating with strings. strings strings strings. I adore this. Unixoids even HTTP made a text protocol (and almost all application level protocols)! Programs communicate with each other with human readable strings. Moronic.
Uhm... what? I think you are confusing the file format with how it is displayed by objdump. While I agree that the Unix fixation on ASCII string data is ill-considered, in this case your rage is misplaced - the ELF format
doesn't save these as strings everywhere. The only strings normally found in an ELF file are... the initialized string constants. Well, that, and the labels using for linking to external code and data - which are necessary in pretty much
any object format for linking, whether statically or dynamically - and debugging. Since the debugging symbols and names of resolved labels can be stripped out if you don't need them (using the
strip utility), that pretty much leaves the string constants, and the names of any unresolved external run-time labels
Again,
the Wicked-Pedo article goes into detail about the format of the headers, as does the
ELF entry in the OSdev wiki.
- The only 'string' in the file header is the file type marker, 'ELF', which was used mainly to make it easier for programs that are expecting text data to recognize that it is a binary file through a simple comparison. This is followed by several enums stored as integers in binary.
- The program headers consist of one integer enum, followed by a set of flags, followed by a segment offset, a virtual address and a physical address, the sizes of the code or data in both the file and the memory image, another set of flags, and an alignment marker (which is basically a flag, too). None of these are strings.
- The section headers have one string, the section ID. The rest are three integer enums, a virtual address, an offset for the location of the section in the file image, the size of the file image in bytes, a pair of unions whose meaning depends on the enums earlier, an alignment index, and a field size used for certain section types but ignored otherwise.
I am failing to see where there are a lot of unnecessary strings. Perhaps you were referring to something else?
zaval wrote:bss. oh please, this bss thing is not even needed. looks like it must be invented to make elf shine.
You are aware that PE (and pretty much every other linkable and/or relocatable object format ever designed) has BSS meta-data, even if not by that name? It defines the locations of run-time data that isn't initialized - that is, it has addresses/offsets and sizes, but no actual data. Or in the case of unresolved symbols, the locations of symbol table entries, and sizes.
Note that ELF doesn't not actually call these sections .BSS; the name given in the documentation to the relevant enum value (0x8) for the
sh_type field of the section header is
SHT_NOBITS.
Here is
what Wicked-Pedo has to say about .bss sections:
In computer programming, the name .bss or bss is used by many compilers and linkers for the portion of an object file or executable containing statically-allocated variables that are not explicitly initialized to any value. It is often referred to as the "bss section" or "bss segment".
Typically only the length of the bss section, but no data, is stored in the object file. The program loader allocates memory for the bss section when it loads the program. On some platforms, some or all of the bss section is initialized to zeroes. Unix-like systems and Windows initialize the bss section to zero, allowing C and C++ statically-allocated variables initialized to values represented with all bits zero to be put in the bss segment. Operating systems may use a technique called zero-fill-on-demand to efficiently implement the bss segment.
Historically, BSS (from Block Started by Symbol) is a pseudo-operation in UA-SAP (United Aircraft Symbolic Assembly Program), the assembler developed in the mid-1950s for the IBM 704 by Roy Nutt, Walter Ramshaw, and others at United Aircraft Corporation.
In C, statically-allocated objects without an explicit initializer are initialized to zero (for arithmetic types) or a null pointer (for pointer types). Implementations of C typically represent zero values and null pointer values using a bit pattern consisting solely of zero-valued bits (though this is not required by the C standard). Hence, the BSS segment typically includes all uninitialized objects
If this is the 'strings string strings' you were talking about, well, how would you store a label as anything
other than a string? The only thing I can think of is some kind of hash, but then, how would you resolve a hash collision? The strings are needed in the case of externals, because
the label is all the other file has to refer to an external element. In any case, as I said, my understanding is that in an unlinked (or dynamically linked) ELF file, the labels aren't in the .bss itself, they are in a separate
SHT_SYMTAB (sh_type == 0x02),
SHT_DYNAMIC (0x06) or
SHT_SYMTAB_SHNDX (0x012) section.
LOL. never saw drooling on the ELF file format yet.
And I told what I dislike about it.