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

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

Re: What form of executable or load module for your OS?

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: What form of executable or load module for your OS? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-24 22:31 -0400
    Re: What form of executable or load module for your OS? "James Harris" <james.harris.1@gmail.com> - 2015-07-01 10:33 +0100
      Re: What form of executable or load module for your OS? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-01 16:14 -0400

#8249 — Re: What form of executable or load module for your OS?

On Wed, 24 Jun 2015 07:34:47 -0400, James Harris  
<james.harris.1@gmail.com> wrote:

> If you have a working OS what form of executable does it load and  
> execute, of if your OS is in development what form of executable are you  
> thinking to support?

Are you saying my OS is not working simply because it can't load
and execute other code?

Tsk tsk ..

> First, for me, whatever format is used needs to be a form that can be  
> constructed by existing build tools so that I can create modules in that  
> form. Presumably you had or have the same issue, unless you made your  
> own build tools.

I'm in the long, slow process of the latter ...

> Second, it needs to be a form that can be constructed without the  
> toolchain building-in something specific to an existing OS (unless my OS  
> is going to support that feature which is unlikely).

Hexdump.

unsigned char bin[]=
{
#include "dump.h"
}

dump.h
0x00,0x01,0x02, ...
0x00,0x01,0x02, ...
...

I'm just joking, but that can be used, although rudimentary.
You could even parse raw text hex if you wanted, e.g., A9143DE ...
If it's already an object, that's what the linker is for.

> I have been thinking of supporting multiple formats, as follows.
>
> Rather than linking at compile time I would prefer to have apps  
> distributed as folders of object modules.

Uh.  Would that mean you need a database to find them?
Or, do you intend to use/abuse the filesystem for that?

> So with that long explanation done the situation is that I am wondering  
> what object formats and executable formats to use for apps.

Whatever works? ...

I.e., why lock-in to a format you might not want?
E.g., DJGPP is stuck with COFF since ELF wasn't a choice at first.

You should only really need one executable format.

> For your OS do you have any of these in mind or already working?

In mind? ...

Working? No.

> If so, just out of curiosity, how did you choose what
> formats to support?

The compiler chose it for me.  I.e., DJGPP uses a COFF
variant for executables and objects.  My original goal
wasn't an OS, but an environment which would load DJGPP
apps.  I now have the start of that too, a non-OS environment
which can load DJGPP apps.  The other compiler I was using
for my OS, OpenWatcom, I had no serious intention of
supporting executables from it.  It generates code which
isn't relocatable for it's DPMI apps.


Rod Pemberton

-- 
It's time to put an end to gun violence!
Use a hammer ...

[toc] | [next] | [standalone]

#8255

"Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message 
news:op.x0rlbhj1yfako5@localhost...
> On Wed, 24 Jun 2015 07:34:47 -0400, James Harris 
> <james.harris.1@gmail.com> wrote:
>
>> If you have a working OS what form of executable does it load and 
>> execute, of if your OS is in development what form of executable are 
>> you  thinking to support?

...

>> First, for me, whatever format is used needs to be a form that can be 
>> constructed by existing build tools so that I can create modules in 
>> that  form. Presumably you had or have the same issue, unless you 
>> made your  own build tools.
>
> I'm in the long, slow process of the latter ...

I went in the same direction, even including a language design. That 
deviation has taken years ... so far!

...

>> Rather than linking at compile time I would prefer to have apps 
>> distributed as folders of object modules.
>
> Uh.  Would that mean you need a database to find them?
> Or, do you intend to use/abuse the filesystem for that?

It could be either. A hierarchy in the file system would be preferred.

For any given element the idea is that there would be a designated 
master copy. That master copy could be a file or folder in the file 
system. If so then if that copy was changed then the OS would rebuild 
any load module which included the changed element.

Alternatively the master could be on a remote computer and the local 
version would just be a cached copy. If so then if the remote computer's 
copy changed then the local copy would be updated. Then any load module 
which used that changed copy would be rebuilt.

Versioning needs to be added to that simple model so that apps can 
choose which version or versions of another module they will use.

>> So with that long explanation done the situation is that I am 
>> wondering  what object formats and executable formats to use for 
>> apps.
>
> Whatever works? ...
>
> I.e., why lock-in to a format you might not want?
> E.g., DJGPP is stuck with COFF since ELF wasn't a choice at first.

Good point. As mentioned to Brendan just now I am thinking that there 
should be a way to write a common set of handler functions (an API, if 
you like) that will work with different types of object file.

The key operations seem to be these:

* Iterate over each section.

* Identify each section type (code/data/bss/stack etc).

* Pick a start section (where the program is to begin).

* Iterate over relocations, fixing up each type.

Perhaps there is a common way to do that regardless of the type of 
object file being read.

Aside... I wonder if it would be possible to link symbols from different 
types of object file so that an instruction in a COFF file could refer 
to a symbol in an ELF file, for example. Just a thought.

> You should only really need one executable format.

Yes, at least one per target architecture. Ideally I need to build that 
myself rather than use an exising one. For example, I don't understand 
ELF's inclusion of a load address, specifically how the address is 
chosen and whether an ELF executable with a pre-designated load address 
can still be relocated or not.

James

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

#8261

On Wed, 01 Jul 2015 05:33:29 -0400, James Harris
<james.harris.1@gmail.com> wrote:

> Aside... I wonder if it would be possible to link symbols from
> different types of object file so that an instruction in a COFF
> file could refer to a symbol in an ELF file, for example. Just
> a thought.

That makes me think of Agner Fog's OBJCONV object converter.


Rod Pemberton

-- 
Tolerance and socialism attracts intolerance and terrorism.  See:
France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ...

[toc] | [prev] | [standalone]

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

csiph-web