Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.development > #9549 > unrolled thread

Questions about the Implementation of the ELF format

Back to article view | Back to alt.os.development

Contents

  Questions about the Implementation of the ELF format "Isaac D. Cohen" <8switchsoftware@gmail.com> - 2016-05-23 22:07 -0700
    Re: Questions about the Implementation of the ELF format Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-05-24 03:48 -0400
    Questions about the Implementation of the ELF format Peter Cheung <mcheung63@gmail.com> - 2016-05-24 01:10 -0700
    Re: Questions about the Implementation of the ELF format "Alexei A. Frounze" <alexfrunews@gmail.com> - 2016-05-24 01:18 -0700
    Re: Questions about the Implementation of the ELF format "Mike Gonta" <mikegonta@gmail.com> - 2016-05-24 10:34 -0400
    Re: Questions about the Implementation of the ELF format Herbert Kleebauer <klee@unibwm.de> - 2016-05-24 17:24 +0200
    Re: Questions about the Implementation of the ELF format "Isaac D. Cohen" <8switchsoftware@gmail.com> - 2016-05-24 14:18 -0700
      Re: Questions about the Implementation of the ELF format "Alexei A. Frounze" <alexfrunews@gmail.com> - 2016-05-25 02:21 -0700
    Re: Questions about the Implementation of the ELF format "Isaac D. Cohen" <8switchsoftware@gmail.com> - 2016-05-25 15:02 -0700
      Re: Questions about the Implementation of the ELF format "Mike Gonta" <mikegonta@gmail.com> - 2016-05-25 19:03 -0400
        Re: Questions about the Implementation of the ELF format "Isaac D. Cohen" <8switchsoftware@gmail.com> - 2016-05-26 14:51 -0700
          Re: Questions about the Implementation of the ELF format Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-05-27 02:55 -0400
            Re: Questions about the Implementation of the ELF format "Isaac D. Cohen" <8switchsoftware@gmail.com> - 2016-05-27 13:43 -0700
              Re: Questions about the Implementation of the ELF format "Mike Gonta" <mikegonta@gmail.com> - 2016-05-27 17:40 -0400
                Re: Questions about the Implementation of the ELF format "Isaac D. Cohen" <8switchsoftware@gmail.com> - 2016-05-28 20:15 -0700
                  Re: Questions about the Implementation of the ELF format Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-05-29 02:35 -0400
                    Re: Questions about the Implementation of the ELF format "Isaac D. Cohen" <8switchsoftware@gmail.com> - 2016-06-15 13:51 -0700
          Re: Questions about the Implementation of the ELF format Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-05-27 03:09 -0400
          Re: Questions about the Implementation of the ELF format "Alexei A. Frounze" <alexfrunews@gmail.com> - 2016-05-27 00:10 -0700
          Re: Questions about the Implementation of the ELF format Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-06-02 16:25 -0400
        Re: Questions about the Implementation of the ELF format Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-05-27 02:38 -0400
          Re: Questions about the Implementation of the ELF format "Mike Gonta" <mikegonta@gmail.com> - 2016-05-27 04:11 -0400
      Re: Questions about the Implementation of the ELF format "Alexei A. Frounze" <alexfrunews@gmail.com> - 2016-05-25 22:18 -0700

Page 2 of 2 — ← Prev page 1 [2]

#9572

On Wed, 25 May 2016 19:03:38 -0400
"Mike Gonta" <mikegonta@gmail.com> wrote:

> first. "start" of course could be a function in the "C" file.
> If the loaded binary is a "C" file then use the #include
> __asm__ ("jmp main");

Hey Mike, you've mentioned that twice lately.  I know it likely doesn't
matter in this situation, but technically, C's main() is called from
stub code instead of being jumped to.  This is because main() returns a
value, an int.  Of course, for a custom OS, main() should never return,
therefore a jump should be fine.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#9576

"Rod Pemberton" wrote:
> "Mike Gonta" wrote:
>
>> first. "start" of course could be a function in the "C"
>> file. If the loaded binary is a "C" file then use the
>> #include
>> __asm__ ("jmp main");
>
> Hey Mike, you've mentioned that twice lately.  I know it
> likely doesn't matter in this situation, but technically,
> C's main() is called from stub code instead of being
> jumped to.  This is because main() returns a value, an int.
> Of course, for a custom OS, main() should never return,
> therefore a jump should be fine.

Technically this is the "stub code".
It permits the loaded code to be called from the boot loader
(and return to the boot loader). Since it's the first
instruction located at the very beginning and at the loaded
address the boot loader (or OS loader) calls the loaded
address and doesn't require a header to provide an entry
address. It's a minimal crt0 - the only other thing required
is a stack (which on a simple system can be the same boot
loader/OS. Loading an OS kernel is only one of many
possibilities for a boot loader which could also be
standalone games, utilities and code snipits.
It's simple to call a function at a load address in "C":
  ((int (*))0x100000)(argc, argv);


Mike Gonta
look and see - many look but few see

http://mikegonta.com
http://tawk.to/mikegonta

[toc] | [prev] | [next] | [standalone]

#9566

On Wednesday, May 25, 2016 at 3:02:21 PM UTC-7, Isaac D. Cohen wrote:
> > Paging exists to fool big fat programs into believing they have 
> > lots of fast and expensive RAM to use when in fact most of it 
> > is backed by your cheap and slow disk storage. Virtual memory 
> > it is.
> 
> It also exists to solve the relocation problem. :)

Virtual address space (not to be confused with paging)
solves only a part of it.

> > Position-independent code is a good thing, but it's not always 
> > cheap (the CPU simply may have no decent PC-relative addressing) 
> > and it itself may need a tiny bit of relocation.
> 
> > Let's say you have this tiny bit of C code: 
> 
> > #include <stdio.h> 
> 
> > int a = 123; 
> > int* pa = &a; 
> 
> > int main(void) 
> > { 
> >   printf("%d\n", *pa); 
> >   return 0; 
> > } 
> 
> > On the x86, direct calls are PC-relative, so calling printf() 
> > may be deemed covered in terms of position independence. 
> > But data accesses to pa and a in non-64-bit modes are not 
> > PC-relative. Hence relocations and/or complex indirection 
> > schemes. 
> 
> > OTOH, in the 64-bit mode you can access both pa and a relative 
> > to PC. However, how does pa get its initial value, the address 
> > of a? There must be some code somewhere that takes the address 
> > of a and stores it in memory at the address of pa. That is a form 
> > of relocation. Bummer! 
> 
> But what does ELF have to do with this whole thing? I understand that certain
> things are relative and certain things have to be relocated. But what does ELF
> have to do with it? Why can't we just compile position independent code when we
> need it and when not, use pure binary files? Obviously we would need paging in
> order to solve the relocation problem with these pure binary files, but wouldn't
> the same thing be necessary for ELFs?

I think I've given you enough reasons why complex executable
formats exist. But let's put it into simpler terms. You need
to delimit executable code and the data that's gonna be used
at run time from other supporting (meta)data, which is neither
of these two. That necessitates some kind of structure or
format in the executable file with headers, sections and all.
Your Windows and Linux executables dynamically link to
libraries that bridge app code with OS system calls and some
useful libraries. The file format must somehow describe
bindings to those libraries (e.g. by library+function name
and by telling the loader where to store addresses of
linked libraries).

Alex

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | alt.os.development

csiph-web