OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 2:40 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 27 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Just to confirm: Is this how ELF files should be readed?
PostPosted: Sat Jun 09, 2018 11:03 am 
Offline
Member
Member
User avatar

Joined: Mon Dec 28, 2015 11:11 am
Posts: 401
Kernel specifically.
Just to be sure, is this okay?:
Bootloader reads the kernel file;
Then it finds N program header tables specified by ELF header and copies each one with type=1 to p_vaddr;
And then moves the instruction pointer (jumps) to the entry point specified by the ELF header.
If I'm wrong somewhere, can you please tell me what I'm doing wrong and how are they supposed to be read?
Can I just read the kernel file at image base address and jump to the entry point?


Top
 Profile  
 
 Post subject: Re: Just to confirm: Is this how ELF files should be readed?
PostPosted: Wed Jun 27, 2018 4:08 am 
Offline
Member
Member

Joined: Sat Sep 24, 2016 12:06 am
Posts: 90
Your bootloader must laod a binary file, ELF isn't the simpliest file structure, just OBJCOPY it to binary file and everything will be OK. else u can load ELF file as needed with remapping and other.
With great regards,
Aleksandr


Top
 Profile  
 
 Post subject: Re: Just to confirm: Is this how ELF files should be readed?
PostPosted: Wed Jun 27, 2018 5:07 am 
Offline
Member
Member

Joined: Wed Aug 30, 2017 8:24 am
Posts: 1593
@MrLol: Your bias is showing. ELF is very simple. Watch:

@Lukand: No copying should take place. Bootloader works in non-paged or identity-paged mode. Once the image is loaded (to a page boundary), iterate over all program headers and map "base + p_offset" to "p_vaddr" (where "base" is the base address of the kernel image), for the length of "p_memsz". Increase the length accordingly if you have to page-align p_vaddr. This works because p_offset and p_vaddr must be congruent to each other, modulo page size.

For the kernel you will need a linker script however, that ensures that the BSS sections are the very last thing in the file, and that the data section is page-aligned (this prevents a safety/security issue, where the last page of code would be mapped into the writable data section).

When your kernel is then itself loading ELF files, also remember to set the difference between p_filesz and p_memsz to 0. For the kernel that isn't necessary, since you can zero your BSS yourself.

Anyway, back to the bootloader: You then have to add an identity mapping for the routine in your bootloader which will enter the kernel. That routine should then enable paging or switch page tables, switch modes to whatever the kernel expects, and jump to the unaltered entry point (from the ELF header). The kernel will then have to clear the BSS section and all mappings from the lower half and that's the end of that.

@MrLol: Try that with a PE file. And a pure binary lacks a way to tell you where it'd like to run, how large its memory image is or where the entry point should be.

_________________
Carpe diem!


Top
 Profile  
 
 Post subject: Re: Just to confirm: Is this how ELF files should be readed?
PostPosted: Sun Jul 01, 2018 1:18 am 
Offline

Joined: Sun Jul 07, 2013 7:29 pm
Posts: 16
I agree that ELF is a great binary file format. It is easy to parse (use elf.h from GNU projects). And the format is much more flexible and powerful that just plain OBJCOPied binary.


Top
 Profile  
 
 Post subject: Re: Just to confirm: Is this how ELF files should be readed?
PostPosted: Sun Jul 01, 2018 6:26 am 
Offline
Member
Member
User avatar

Joined: Fri Feb 17, 2017 4:01 pm
Posts: 640
Location: Ukraine, Bachmut
Quote:
And the format is much more flexible and powerful that just plain OBJCOPied binary.

so, its format is much more flexible than the absence of any format. great format. :mrgreen: LOL. never saw drooling on the ELF file format yet.

And personally I have a dream, in my work, - to get rid of it. :D

_________________
ANT - NT-like OS for x64 and arm64.
efify - UEFI for a couple of boards (mips and arm). suspended due to lost of all the target park boards (russians destroyed our town).


Top
 Profile  
 
 Post subject: Re: Just to confirm: Is this how ELF files should be readed?
PostPosted: Sun Jul 01, 2018 10:34 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
zaval wrote:
And personally I have a dream, in my work, - to get rid of it. :D


ELF specifically, or executable object formats in general? I'm curious to hear your reasoning, either way; you have often stated a dislike of ELF, but never said much about why.

Mind you, I have no horse in this race; while I do plan to make a library for working with ELF so that I can use my toolchain in Linux, it has no connection to my OS (which will work almost exclusively with JIT off of an AST-based portable format, and won't have, you know, files in the conventional sense at all). Not that I will ever get that far anyway, but still.

The point is that you are saying a lot of off the cuff things without ever explaining them, and I suspect that this reticence to do so is making it harder for the rest of us to understand what you are trying to accomplish.

We may need to take this to a separate thread, probably in either 'OS Theory' or 'General Ramblings' rather than here, as it is likely to go well beyond just discussing ELF. I know, for instance, that your opinions of both Linux and the RPi are quite low - lower than my own opinion of the x86 architecture, and that's saying something - but the reasons why are clear, so saying more about that might help. I won't judge you if the reasons are personal - if it is just a gut dislike, simply say so - but it would help if we simply knew why.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: Just to confirm: Is this how ELF files should be readed?
PostPosted: Sun Jul 01, 2018 3:33 pm 
Offline
Member
Member
User avatar

Joined: Fri Feb 17, 2017 4:01 pm
Posts: 640
Location: Ukraine, Bachmut
Schol-R-LEA wrote:
ELF specifically, or executable object formats in general? I'm curious to hear your reasoning, either way; you have often stated a dislike of ELF, but never said much about why.

specifically it. that's because I forced to use it whereas I don't want to. :) And I told what I dislike about it.
I don't like segments, sections are enough, and I don't like the PIC approach it forces on libraries (shared objects). I want to have DLLs - relocatable dynamically loadable/unloadable libraries, right what PE gives, - base relocations, IAT/EAT and all that. With ELF, it's not possible (easy if at all).
However, my anti-unix zealotry doesn't prevent me from having the wish/idea of supporting this format, for the future POSIX subsystem. I am not a hopeless irrational fanatic. :) I am interested to adapt things, even if they are posix. :D there are loads of free posix programs, it's interesting to make them run on my OS without much of modifications. conformism rules. :lol:
Quote:
Mind you, I have no horse in this race; while I do plan to make a library for working with ELF so that I can use my toolchain in Linux, it has no connection to my OS (which will work almost exclusively with JIT off of an AST-based portable format, and won't have, you know, files in the conventional sense at all). Not that I will ever get that far anyway, but still.

The point is that you are saying a lot of off the cuff things without ever explaining them, and I suspect that this reticence to do so is making it harder for the rest of us to understand what you are trying to accomplish.

That's not exactly true. Maybe my ability to explain sucks in addition to my sucky english, but at least I think I has been trying to explain why I dislike something when saying those "cuff" things.
And of course I am a newbass that may be wrong in so many points. no matter how hard to admit it is.
Quote:
We may need to take this to a separate thread, probably in either 'OS Theory' or 'General Ramblings' rather than here, as it is likely to go well beyond just discussing ELF. I know, for instance, that your opinions of both Linux and the RPi are quite low - lower than my own opinion of the x86 architecture, and that's saying something - but the reasons why are clear, so saying more about that might help. I won't judge you if the reasons are personal - if it is just a gut dislike, simply say so - but it would help if we simply knew why.

nobody messing around with arm SBCs loves RPi except RPi fan boys. :D that's because it is not the best in any view contrary to what its "community" is chanting constantly.
1) it's not the "teh most firstest arm board ever" that had appeared on this planet, as they wanna make all believe in
2) it's not the cheapest one, more importantly - not the best by the price/capabilities ratio
3) it's rather feature down-grading with respect to the "progress" on this arena - those broadcom SoCs are hopeless underdogs, they suck compared to competitors really bad.

there are so much better boards, they deserve more attention from the general public, instead it always ends up with babbling on "RPi"... RPi is not friendly even for system programming, since Broadcom bastardized the whole low level boot chain (more than others did), by embedding there that monster VideoCore thing, that is a mutant that is claimed to be a GPU with some "God mode" abilities to decide on what to "let" CPU do or what not. And of course, it's not open at all.

as of linux, is it needed to start "holy wars" disturbing fans? I thought I avoided feces throwing at it pretty thoroughly. :D well, if to answer, I'll try as a brief list of highly biased imos:
1) poor quality, mediocrity, aka "just works, gtfo", lack of attraction, not being nor evolving into something interesting.
2) arrogance, hostility, bigotry, psychopathy
3) outlying/foreign ideas, concepts, "philosophy".
Sorry, I just don't see anything kewl in that Unix calque.

_________________
ANT - NT-like OS for x64 and arm64.
efify - UEFI for a couple of boards (mips and arm). suspended due to lost of all the target park boards (russians destroyed our town).


Top
 Profile  
 
 Post subject: Re: Just to confirm: Is this how ELF files should be readed?
PostPosted: Sun Jul 01, 2018 4:52 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
Fair enough.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: Just to confirm: Is this how ELF files should be readed?
PostPosted: Fri Jul 06, 2018 12:42 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
Actually, no, not fair enough. Your comments about ELF indicate to me that you don't understand either ELF or PE. I have no problem with it if you dislike ELF (there are plenty of valid reasons to, and frankly someone doesn't really need a reason for something to rub them the wrong way), but I suspect that part of why dislike it is based on misunderstandings.

First off, the reason for a separate program header for segments and section header for sections is because they do two completely different things. The fact that the PE format doesn't separate the two doesn't mean it doesn't have that additional information that ELF puts in the program (segment) header. I may be wrong, but I am guessing that several of the parts of the PE header you have dismissed as 'I don't need to worry about that' are basically the same meta-data as in the ELF program header.

However, it has been a while since I looked at PE, so I am not sure. I just bought the Kindle version of the Girder Book, though, so I will try to refresh my knowledge. ($55, ouch, but it is worth every penny.)

Second - and please correct me if I am wrong - I am quite certain that PIC is not required for shared libraries in ELF in general, or even Linux in general (and keep in mind that the two are not the same - ELF came from Solaris IIRC, and Linux systems originally used a.out or COFF, and I am pretty sure they still can be built to do so; switching to ELF from a.out as the default format was actually quite controversial in the late 1990s). The 'requirement' to use PIC isn't one at all; it is just how the majority of popular Linux distros happen to do it.

Indeed, several of the ISAs for which ELF can be used , such as (IIUC) IBM Z series running AIX, don't even support PIC.

EDIT: Not Solaris, according to Wicked Pedo it was introduced in the updated ABI for System V releaee 4 in 1988. Linux was originally based on BSD (or at least seemed to borrow more from it than from SVR4) and so didn't adopt ELF until later. But I am still pretty sure you can build Linux to use other formats even now.

I am not sure why you say that you are forced to use ELF. Even if you are using GCC and Binutils - and that is by no means the only feasible tool chain - they are perfectly capable of generating and working with several other formats. IIUC, you are using Windows as your dev host, so you must know that Windows ports such as MINGW and Cygwin produce PE by default. Similarly, GRUB (which you aren't using anyway) and other boot loaders such as Boot Magic also support multiple kernel formats.

However, I know that you work extensively with SBCs, and IIRC some of those do require an ELF file for the kernel; in that instance, I would say you are indeed forced to use it, but I don't know if this is the case with any of the SBCs you are targeting.

I do agree with a lot of your general complaints about Linux and the Linux community, however, though IMO Windows and Mac are just as bad even if it is in different ways. I expect that the reason you are here is because you feel similarly.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Last edited by Schol-R-LEA on Fri Jul 06, 2018 7:40 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Just to confirm: Is this how ELF files should be readed?
PostPosted: Fri Jul 06, 2018 2:53 pm 
Offline
Member
Member

Joined: Fri Aug 19, 2016 10:28 pm
Posts: 360
Schol-R-LEA wrote:
Second - and please correct me if I am wrong - I am quite certain that PIC is not required for shared libraries in ELF in general, or even Linux in general
That is correct. The elf format is much more permissive than the gnu toolchain, which is more permissive than the current "community guidelines". The distributions are trying to use pic on x64, but the toolchain can use pic and non-pic, if the latter is combined with -mcmodel=large. Both are supported by the dynamic loader. I see no reason why the elf format wouldn't be able to describe even non-pics built with -mcmodel=small, but gcc is not designed to generate the necessary code at the moment and the loader may not allow it. The relocation types should be able to handle it though.

The PE relocations are serviceable, but more limited. When mingw emulates elf relocations on PE, it provides special code that applies additional fix-ups to the pseudo-GOT during initialization. It is sort-of a mess. Msvc applies relocations directly to the text section, so memory sharing is rarely possible. (Edit: I think Windows actually fixes this by performing once-per-boot ASLR for all images, such that their base address coincides in all address spaces.) On x64, it may be possible for most pages, because rip relative addressing reduces the number of relocations altogether.

The usual advice for solving a linking error for a shared object, when it complains for bad relocations type, is to, of course, "recompile with -fPIC". But this is not the only option.


Top
 Profile  
 
 Post subject: Re: Just to confirm: Is this how ELF files should be readed?
PostPosted: Fri Jul 06, 2018 7:02 pm 
Offline
Member
Member
User avatar

Joined: Sun Oct 22, 2006 7:01 am
Posts: 2646
Location: Devon, UK
zaval wrote:
so, its format is much more flexible than the absence of any format. great format. :mrgreen: LOL.


Yes. In this case a format provides more flexibility than lack of a format.

The flexibility comes from knowing what part of the file goes where, from having symbols to link against, from having a known size bss which does not need to reside in the binary file...the list goes on.

Schol-R-LEA wrote:
Actually, no, not fair enough. Your comments about ELF indicate to me that you don't understand either ELF or PE. I have no problem with it if you dislike ELF (there are plenty of valid reasons to, and frankly someone doesn't really need a reason for something to rub them the wrong way), but I suspect that part of why dislike it is based on misunderstandings.

+1

Schol-R-LEA wrote:
However, I know that you work extensively with SBCs, and IIRC some of those do require an ELF file for the kernel; in that instance, I would say you are indeed forced to use it, but I don't know if this is the case with any of the SBCs you are targeting.


Even on most SBCs with restrictive boot protocols like the RPI, theres nothing stopping you creating an ELF stub to load your flat binary. I don't know why you'd want to do that, but the point is it can be done.

Cheers,
Adam


Top
 Profile  
 
 Post subject: Re: Just to confirm: Is this how ELF files should be readed?
PostPosted: Fri Jul 06, 2018 7:48 pm 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
I will repeat what I said earlier, and have said many times here before: John Levine's textbook Linkers and Loaders is well worth reading, even if you just stick to the freely-downloadable beta version from his website. It has fine coverage of several executable formats, including ELF, PE, and COFF (which apparently was a bigger influence PE than either the MS-DOS MZ format or the 16-bit Windows NE format). While it is now nearly 20 years old, the topic hasn't really changed that drastically, so it is still quite relevant even though he doesn't cover some more recent developments such as x86-64 and AArch64. A lot of university libraries have a copy, at least in the US (I have no idea about elsewhere), and while the price of the Kindle or of a new copy is steep, there are probably used copies that are a lot more reasonable.

Also, I am guessing that this Wikipedia entry comparing executable file formats might be relevant for this discussion, but I think I will wait for Zaval to reply before saying anything more.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: Just to confirm: Is this how ELF files should be readed?
PostPosted: Sat Jul 07, 2018 8:09 am 
Offline
Member
Member
User avatar

Joined: Fri Feb 17, 2017 4:01 pm
Posts: 640
Location: Ukraine, Bachmut
Schol-R-LEA wrote:
First off, the reason for a separate program header for segments and section header for sections is because they do two completely different things.

what things? sections in ELF don't do anything.
Quote:
The fact that the PE format doesn't separate the two doesn't mean it doesn't have that additional information that ELF puts in the program (segment) header. I may be wrong, but I am guessing that several of the parts of the PE header you have dismissed as 'I don't need to worry about that' are basically the same meta-data as in the ELF program header.

it's comparing apples and oranges. PE operates on sections as mapping entinties. No need of "segments". If you think .txt and .rdata and maybe even .idata (import) should be merged into one, just do it with the linker script - emit one output section for them - that's all, everything has been devised already. Segments are the same sections, just unnecessarily made as independent entities. but what linker sections do in ELF then? nothing. mess.

PE has a directory for metadata it's a part of the optional header. Those metadata point to different places inside the image - import/export/relocations/debug etc. those places might be sections or might be part of other sections. It's all clear and easy to comprehend, and no it's not an excuse of why ELF wanted to have segments whereas sections were enough.

Quote:
Second - and please correct me if I am wrong - I am quite certain that PIC is not required for shared libraries in ELF in general, or even Linux in general (and keep in mind that the two are not the same - ELF came from Solaris IIRC, and Linux systems originally used a.out or COFF, and I am pretty sure they still can be built to do so; switching to ELF from a.out as the default format was actually quite controversial in the late 1990s). The 'requirement' to use PIC isn't one at all; it is just how the majority of popular Linux distros happen to do it.

Indeed, several of the ISAs for which ELF can be used , such as (IIUC) IBM Z series running AIX, don't even support PIC.

EDIT: Not Solaris, according to Wicked Pedo it was introduced in the updated ABI for System V releaee 4 in 1988. Linux was originally based on BSD (or at least seemed to borrow more from it than from SVR4) and so didn't adopt ELF until later. But I am still pretty sure you can build Linux to use other formats even now.

I am not sure why you say that you are forced to use ELF. Even if you are using GCC and Binutils - and that is by no means the only feasible tool chain - they are perfectly capable of generating and working with several other formats. IIUC, you are using Windows as your dev host, so you must know that Windows ports such as MINGW and Cygwin produce PE by default. Similarly, GRUB (which you aren't using anyway) and other boot loaders such as Boot Magic also support multiple kernel formats.

Ok. How do I produce a DLL-like library with ELF? not PIC. What excatly ELF should I choose? "executable"? nope, it has a predefined (at link time) address and relocations are lost. Until you ask to hold them. But they are not meant for "base relocations" this f&cking sh1t doesn't even have a notion of image base, they happily could be left "for analyzing software". And it shows, basically all it gives - the possibility of translation the resulting executable ELF into PE. But this is not enough! Where import/export capabilities are? Does ELF executable have means for exporting/importing as PE does? all it has is absolutely not fitting with the DLL mechanism. I need manually embed them turning into PE wrapped in ELF. Basically it's what I do. Something like this (it's very simplistic, this is DXE phase of the mips port importing some useful functions from SEC).
Code:
/* 22:56 21.11.2017
*
*
*/

.set noreorder
.set nomacro
.set mips32r2
.set nomips16
.set nomicromips
.set noat

.global   IDT, PutString, PutChar, PrintUint32, GetTickCount, WaitPeriods, CompareGuid

.section .idata, "a", @progbits

SEC_IAT:
PutString:   .word   0x80000001
PutChar:   .word   0x80000002
PrintUint32:   .word   0x80000003
GetTickCount:   .word   0x80000004
WaitPeriods:   .word   0x80000005
CompareGuid:   .word   0x80000006
      .word   0x00000000

IDT:   .word   SEC_ILT      /* RVA of SEC ILT */
   .word   0x00000000   /* time stamp */
   .word   0x00000000   /* forwarder chain */
   .word   SEC_NAME   /* RVA of DLL string */
   .word   SEC_IAT      /* RVA of SEC IAT */

   .word   0,0,0,0,0   /* end entry */

SEC_ILT:
   .word   0x80000001
   .word   0x80000002
   .word   0x80000003
   .word   0x80000004
   .word   0x80000005
   .word   0x80000006
   .word   0x00000000

SEC_NAME:   .asciz   "SEC"


Then, I produce PE from those elf mutants.

"shared" object? how? tell me. but I don't even want to think about all that GOT/PLT ****! it's PIC and I told I am not interested in it.

For example tell, me:
on PE one could export function by ordinal, a number. No need to even search for string! IDT/IAT/ILT all accomplish that. Look at the code above. how do I do this on ELF?

Most importantly - how can I do this with what is really available (linaro toolchain with elf target)? Not sphaerical horses in vacuum, of how it could be if if if if.
Quote:
However, I know that you work extensively with SBCs, and IIRC some of those do require an ELF file for the kernel; in that instance, I would say you are indeed forced to use it, but I don't know if this is the case with any of the SBCs you are targeting.

No, none of SBCs requires ELF (thanks God!). GCC requires it. I just am not ready to compile (actually - write yet) gcc for ARM/MIPS with PE support. My guts are telling me that it's a hopeless affair. Totally.

Quote:
I do agree with a lot of your general complaints about Linux and the Linux community, however, though IMO Windows and Mac are just as bad even if it is in different ways. I expect that the reason you are here is because you feel similarly.

Honestly, mac fanatics are even bigger morons. :lol: BSD folks look much saner. but among Windows users I see just users. no fanatics biting people. Maybe because it's 93% of all people dealing with personal computers. It's impossible that all 93% were crackpots. :lol:

_________________
ANT - NT-like OS for x64 and arm64.
efify - UEFI for a couple of boards (mips and arm). suspended due to lost of all the target park boards (russians destroyed our town).


Top
 Profile  
 
 Post subject: Re: Just to confirm: Is this how ELF files should be readed?
PostPosted: Sat Jul 07, 2018 8:23 am 
Offline
Member
Member
User avatar

Joined: Fri Feb 17, 2017 4:01 pm
Posts: 640
Location: Ukraine, Bachmut
AJ wrote:
zaval wrote:
so, its format is much more flexible than the absence of any format. great format. :mrgreen: LOL.


Yes. In this case a format provides more flexibility than lack of a format.

The flexibility comes from knowing what part of the file goes where, from having symbols to link against, from having a known size bss which does not need to reside in the binary file...the list goes on.

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.

bss. oh please, this bss thing is not even needed. looks like it must be invented to make elf shine. :lol:
how much data that go into bss, your ordinary program would have? so freaking much space saving... PE for example has file alignment/section alignment notion. That really saves space on the storage. But if you want to page align a section in ELF, it literally puts all those gaps into file. So stupid!
Quote:
Even on most SBCs with restrictive boot protocols like the RPI, theres nothing stopping you creating an ELF stub to load your flat binary. I don't know why you'd want to do that, but the point is it can be done.

Cheers,
Adam

Again, it's all about available toolchains restrictions. Most SBCs' rom codes exactly expect a plain binary, they are not willing to mess around with formatted images.

_________________
ANT - NT-like OS for x64 and arm64.
efify - UEFI for a couple of boards (mips and arm). suspended due to lost of all the target park boards (russians destroyed our town).


Top
 Profile  
 
 Post subject: Re: Just to confirm: Is this how ELF files should be readed?
PostPosted: Sat Jul 07, 2018 10:43 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
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. :lol:


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:

Quote:
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.


Quote:
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.


Quote:
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.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 27 posts ]  Go to page 1, 2  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: DotBot [Bot] and 48 guests


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 post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group