|object/load module formats email@example.com (Shaun Wilkinson) (1994-02-15)|
|object/load module formats firstname.lastname@example.org (1994-02-16)|
|Re: object/load module formats email@example.com (Steven D. Majewski) (1994-02-16)|
|Re: object/load module formats firstname.lastname@example.org (1994-02-16)|
|Re: object/load module formats email@example.com (1994-02-19)|
|Re: object/load module formats firstname.lastname@example.org (1994-02-20)|
|Re: object/load module formats email@example.com (1994-02-24)|
|Re: object/load module formats firstname.lastname@example.org (1994-03-02)|
|[2 later articles]|
|From:||email@example.com (Steve Simmons)|
|Organization:||CONVEX News Network, Engineering (cnn.eng), Richardson, Tx USA|
|Date:||Wed, 16 Feb 1994 13:32:22 GMT|
> We`re thinking of changing the object/load module format of our cross
> tools. Does someone know about standard/popular object/load module format
> which are suitable for our purpose? (we need their documents, license
> free.) What are the current trends in this area?
There are many formats for an object file interface. The real problem
is what are your requirements:
- How many memory types do you have (BSS, DATA, TEXT, etc..)
- Will you have dynamic linking? Then, you need an easy to
access way of resolving addresses at image activation time.
- Are you going to allowing tracebacks at core dump time
like VMS does??? Then, you need at least a simple nlist.
- Are you going to have debug support and do you plan on
putting it in the executable? If it dbx's stabs, you will
augment the nlist.
- What run time flags need to be set in your executable?
Our C-Series allowed for two modes of floating point
execution (IEEE & native). A bit was set in the header
to state which mode.
The reason for the proliferation of object file formats is that everyone
has a little different set of requirements??
Return to the
Search the comp.compilers archives again.