Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| Re: executables johnm@cory.EECS.Berkeley.EDU (1994-12-04) |
| Re: executables tleylan@aloha.com (1994-12-07) |
| Re: executables: COFF c2a192@ugrad.cs.ubc.ca (1994-12-11) |
| Re: executables: COFF sdm7g@elvis.med.virginia.edu (Steven D. Majewski) (1994-12-21) |
| Newsgroups: | comp.compilers |
| From: | c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) |
| Keywords: | linker, comment |
| Organization: | Computer Science, University of B.C., Vancouver, B.C., Canada |
| References: | 94-12-035 94-12-059 |
| Date: | Sun, 11 Dec 1994 08:24:20 GMT |
This material is also interesting to me. I'd like to know the nature
of a.out files, and coff .o files.
As a little experiment, I've been hacking into .o files produced by
DJGPP, and managed to infer a few simple things just from hex dumps, I
can assemble a small .o file containing one routine, and then load it
into an arbitrary address from within a C program and call it.
I'd like to use this as the starting ground for writing OS code that
will set up its own tables for segmentation, paging, exceptions,
tasks, etc. then load in the a.out kernel image of the operating system.
DJGPP under DOS sounds like a reasonable cross-compiler, no? I mean,
you can tell it to not include the standard library or other startup
material when it creates the a.out file.
Is running an a.out file simply a matter of loading the image into a
segment (so that the starting address is a logical 0x0 or 0x1000 or
whatever the a.out needs for static, non-relocatable references to
work) and branching to the entry point?
It doesn't seem like a.out files undergo processing when they are
loaded by Unix, since that would defeat the demand paging mechanism
whereby pages of the program are faulted in at random as the need
arises. This is what leads me to believe that the a.out is just a
block of code compiled to run at a particular logical address.
Where are symbol tables and debugging info located in the a.out? How
exactly are shared libraries implemented - or rather, the linking to
these libraries? Sure, you can map a bunch of code whose entry points
are known into the same logical location within each process and then
use hard jumps, but how does it work dynamically?
I'm sure all of this is simple; it's a matter of getting the right
information, any of which I will appreciate.
-Kaz
[O'Reilly published a thin but good book on COFF, ISBN 0-937175-31-5, don't
know if it's still in print. The SVR3.2 docs also have a surprisingly goof
COFF chapter. -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.