Re: [Tack-devel] [tack-devel] a.out vs. ELF

[Gregory T. (t. K. <gt...@di...>]

David Given wrote:

>...I suspect a lot of the build confusion comes from mistaking headers
> intended to be used by programs compiled *by* the ACK with headers used
>by the
> ACK itself.

Well, I did not understand why ack needed any knowledge it was going to be
in ELF format in order to even compile.  I can understand this at the
output from ack layer, but that wasn't the case.  I could even understand
it if ack was bootstrapping itself, but it wasn't completely clear to me it
was.  I didn't understand why the particular header was being picked up; I
just assumed it had some POSIX functionality in it that ACK needed and for
some reason wasn't provided with the source code.

>  As a result of this, the ACK knows absolutely nothing about shared
>libraries.  However,
> there's no reason why we have to use the ACK's platform. It's
> perfectly possible to compile a program referring to headers in /usr/include,
> link it with led into a partially linked object file (because led can't link
> to shared libraries, of course), exporting it to ELF (using a program yet to
> be written), and then linking the result to shared libraries using the
> platform linker.  If you do this then you'll lose the portability across
>platforms that the ACK
> was originally aiming for, but frankly, that's not particularly important
> these days.

I would say that portability across platforms is critical to maintain.  ACK
is exceptionally well positioned for bootstrapping alternative operating
systems.  I would say that ACK's main draw is going to be for new OSes and
not currently existing ones which are probably quite unlikely to be able to
compile on any toolchain other than gcc.  As such, I would recommend
delaying the file format generation decision as late as possible in the
assembling process.

I am aware that ACK currently does not generate code in high enough quality
to be desirable for kernels.  However, I'd rather fix that problem than
build a kernel tree that is tied very tightly to gcc functionality and
directives that then can not be ported to being built with ACK, XL C, et al.

> I am planning to write two ack.out converters at some point, one for ELF and
> one for a simple binary image; however, I don't know a lot about ELF and so
> this would require a lot of reading up on... it may be easier instead to
> persuade someone who knows about such things to add ack.out support to
>the GNU
> binutils toolchain instead, so that ld can read them in directly. ack.out
> doesn't look very complicated.

ack.out appears to very closely resemble xcoff.  It'd be easy to modify ld
to recognize this format and as Perry indicated in an earlier post, NetBSD
can be compiled for xcoff compatibility.  In conjunction with my statement
about ACK's main draw, simple three section file formats are about as easy
as they get for linking and loading (short of straight binary with entry at
byte 0).  While most kernels are ELF, I know that the NetBSD and OpenBSD
bootloaders strip off extra sections when booting, and are only interested
in the .text, .rodata, and .bss sections when loading the kernel into
memory (and maybe the symbols section if it hasn't been stripped).

/usr/src/sys/lib/libsa/loadfile.c
/usr/src/sys/lib/libsa/loadfile_elf32.c

So while supporting ELF may be desirable and reasonable, I think there are
a lot of arguments for having parallel file formats.  I am concerned that
converters from ELF or to ELF will lose information if other file formats
come into play (like the shared library-friendly PEF format, for example).

tim

Gregory T. (tim) Kelly
Owner
Dialectronics.com

P.O. Box 606
Newberry, SC 29108

"Anything war can do, peace can do better."  -- Bishop Desmond Tutu