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

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

At 1:06 PM -0400 7/20/06, Perry E. Metzger wrote:
>>    #if !defined(_STANDALONE) && !defined(_KERNEL)
>>          #ifdef __GNUC__
>>            #define __RENAME(x)     ___RENAME(x)
>>         #else
>>             #ifdef __lint__
>>                #define __RENAME(x)     __symbolrename(x)
>>              #else
>>                 #error "No function renaming possible"
>>            #endif /* __lint__ */
>>        #endif /* __GNUC__ */
>>      #else /* _STANDALONE || _KERNEL */
>>         #define __RENAME(x)     no renaming in kernel or standalone envir=
onment
>>     #endif
>
>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.  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.

And it might well be an interesting part of the code.  The conditional=
 failing is #ifdef __lint__.  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.

>> 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, 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. =20

(Fully noting that David Given is in charge of the project and I don't mean=
 to imply any insertion of myself in the decision-making process.  I'm=
 looking at ACK for its stated purpose - a portable compiler kit.)

>> 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?

=46rom what I can tell, Tanenbaum's approach is to adhere to POSIX as much=
 as possible and provide implementations of anything extra needed, rather=
 than rely on a specific operating system's version of that functionality. =
 If anyone knows differently, please let me know because I agree with that=
 philosophy (having come from a radically different OS background and=
 routinely found myself excluded from working tools).

>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.  Now, if the particular=
 implementation of lint 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.

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