Re: [Tack-devel] ACK compiles on NetBSD-macppc, sort of...

[Perry E. M. <pe...@pi...>]

"Gregory T. (tim) Kelly" <gt...@di...> writes:
>>This isn't the interesting part of the code. Look, as I said, at the
>>ELF implementation of the macro (for example). You have to read the
>>code and understand how it works, where it is used and why it is used.
>
> I did look at it.  And then I went to find it on OpenBSD and it
> isn't in sys/cdefs.h, which means that symbol renaming is somewhere
> else on OpenBSD (looks like <machine/cdefs.h> and <machine/asm.h>),
> and probably a third place on FreeBSD.  That made me come back and
> say perhaps there are BSD-independent solutions available that
> should be explored, instead of building to NetBSD's version of the
> gcc extensions.  I'm not wanting to use ELF in the output from ACK.

You have no choice. If you don't generate ELF, there is no possibility
at all of using the compiler in the future. The object format on every
platform you deal with is ELF. You won't be able to run non-ELF
userland binaries, since the kernel's loader expects ELF. You won't be
able to build kernels, since the boot loaders expect ELF. You won't be
able to generate shared objects or build kernels or link to dynamic
binaries etc. without ELF. That is true on *BSD, Linux and a dozen
other platforms.

As for the specifics of symbol renaming, you don't need to implement
symbol renaming itself -- you need to make sure that things like the
asm syntax will support it.

> I only want ACK to run on a BSD.  I certainly don't want to build
> ACK output to gcc syntax or anything more than needed to get
> bootstrapped.

You'll have a hard time without producing ELF. How do you plan to load
a non-ELF binary when the kernel expects ELF? :)

> And it might well be an interesting part of the code.  The
> conditional failing is #ifdef __lint__.

I don't think you understood what your read.

>  As far as I can tell, all of the Makefiles use ACK's lint rather
>  than the host-provided (Unix) lint.  Additionally, the path to the
>  failed conditional indicates _GNUC_ is _not_ defined.

Well, of course it isn't defined if you're running ACK, is it?

>>> Is this specific to NetBSD?
>>
>>This specific set of macros are, but almost all modern OSes have some
>>form of symbol versioning. The specifics tend to be fairly OS
>>specific, but they almost all make use of GCC's extended assembler
>>syntax and/or the ability of the assembler to provide things like ELF
>>section directives.
>
> If I have to implement a particular set of extensions to make this
> work on a BSD, I am likely to choose the xcoff/a.out format,

I don't think that's a smart move. :)

Really, what you want is to do what the GNU tools do and have a set of
back ends that are capable of handling multiple formats, but these
days, ELF is just about the only thing that matters.

> since it more closely resembles ack.out, making it one step closer
> to self-hosting (ACK building ACK).  My purpose is to get away from
> the gnu/gcc toolchain, not do it like they do.

ELF is not a gccism. It is a very widely used standard. The only two
formats that are of interest these days are ELF (on Unix) and PECOFF
(on Windows).

How do you plan on loading binaries if you don't use ELF? I don't have
COMPAT_AOUT in my NetBSD kernel, and most people don't. (There would
be no point in having COMPAT_AOUT since I have no a.out shared
libraries to make an a.out program run in the first place.)

>>> Is there a POSIX-like standard that could be applied to the
>>> solution, short of defining _STANDALONE?
>>
>>I have no idea what _STANDALONE has to do with this. You're not
>>writing a boot loader.
>
> According to the Design and Implementation of the 4.4BSD Operating
> System, a standalone program is one that can operate without the
> assistance of the BSD kernel, of which a bootloader is one example.
> According to the same book, there should be a standalone I/O
> library.  Wouldn't this provide a path to avoiding symbol renaming
> specifics?

Sure, if you are trying to run on the raw hardware without an
operating system present at all. The only example of such a program
that anyone cares about is the boot loader. Are you sure you
understand this?

>>Bear in mind, without this sort of thing, you don't have any hope of
>>generating system calls on *any* modern platform. I think there are
>>similar hacks in Solaris but (I think) they use a different set of
>>compiler facilities. Windows does this sort of thing with a vengeance,
>>too.
>
> Well, I'm somewhat at a loss to understand why a userland programmer
> needs to know the specifics of the symbol renaming mechanism of the
> particular OS an application (ACK) is being built for.

The ordinary programmer does not. The COMPILER author does. A compiler
is not an ordinary userland program. A compiler has to deal with all
sorts of things that are not considered by the ordinary programmer,
like the local object format.

>  Now, if the particular implementation of lint

This has nothing to do with lint. Lint is fully machine independent.

> or some other part of the ACK toolchain needs to know these
> specifics, I can accept this, to a point.  Earlier I had asked if
> there was a POSIX-like standard that could be applied, so that
> adherence to that standard would be sufficient and operating system
> particulars were not relevant.  I renew my inquiry.

I am not sure you understand the issue.

Perry