Steel Bank Common Lisp

On Sat, 30 Apr 2005, John Morrison wrote:

> Looking for a sanity-check.  It looks like I get
> undefined-alien-function-errors when trying to call defined "weak"
> alien functions (which include useful things like C++ constructors!).
> Is this expected?  I seem to have no such trouble calling "strong"
> symbols.

I'm aftraid that I don't follow. What do you mean by "weak" and "strong"
alien functions / symbols? Presumably some C++ magic?

Do do you have a test case runnable on a plain vanilla SBCL?

> Unfortunately, in the extremely large C++ code base I'd like to call
> into, there are lots of weak symbols, and this seems to be correlated
> with use of "inline" directives.

Using my ESP powers I predict that your C++ compiler doesn't produce 
linkable symbols / object code for inline functions whose address is never 
taken (or something to that effect anyways).

> If so, my next quest will be to see if I can work some hackery to
> turn these into strong symbols.  I would like to avoid recompiling
> (this is one option) and defining "inline" to be "".  Suggestions
> appreciated.

Possibly a compiler option for C++, or failing that try linking into the 
build something that takes the address of every inline function.

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."

Hi;

On Sunday 01 May 2005 09:49 am, Nikodemus Siivola wrote:
> I'm aftraid that I don't follow. What do you mean by "weak" and "strong"
> alien functions / symbols? Presumably some C++ magic?

=46rom the man page for "nm":

           "W" The  symbol  is  a  weak symbol that has not been specifical=
ly
               tagged as a weak object symbol.  When a weak defined symbol =
is
               linked with a normal defined symbol, the normal defined symb=
ol
               is used with no error.  When a weak undefined symbol is link=
ed
               and  the  symbol  is not defined, the value of the weak symb=
ol
               becomes zero with no error.

I confess, although I've done my fair share of C++ and embedded
systems hackery, I have never seen such a thing.  The only thing I can
guess is it has something to do with multiply-inlined functions, but
last time I got C++ code running on bare x86 metal, I thought this
stuff (including avoiding multiple template instantiations) was all
handled in the linker by some .link_once segment -- maybe this is how
stuff ends up in that segment.

I promise to look deeper (see below), but I was just wondering if
somebody here had ever run into this problem before.

> Do do you have a test case runnable on a plain vanilla SBCL?

I didn't think to do this on my test program -- it first showed up in
the enormous C++ source code deck I'm trying to call.  I will
absolutely put it in my test program with the goal of figuring this
out.

> Using my ESP powers I predict that your C++ compiler doesn't produce
> linkable symbols / object code for inline functions whose address is never
> taken (or something to that effect anyways).

It looks like it is prepared for conflict in these symbols, and would
prefer a "normal" symbol (used when instantiated in a user program).
The "zero with no error" thing is completely inexplicable to me.  (I
am very proud of myself I used no profanity in that last sentence.)

> Possibly a compiler option for C++, or failing that try linking into the
> build something that takes the address of every inline function.

There is a -fno-inline directive, but I'm not sure yet if this will Do
The Right Thing (when was the last time "C++" and "Right Thing" ever
appeared in the same sentence, asked the man who is now sitting in on
lunchtime seminars on template-template metaprogramming as written in
Alexandrescu's "Modern C++ Design")?

       -fno-inline
           Don't pay attention to the "inline" keyword.  Normally this opti=
on
           is used to keep the compiler from expanding any functions inline.
           Note that if you are not optimizing, no functions can be expanded
           inline.


Please don't let my sarcasm/venting/ranting put you off -- I'm very
grateful for the help.

=2Djm

>
> Cheers,
>
>   -- Nikodemus              Schemer: "Buddha is small, clean, and serious=
=2E"
>                    Lispnik: "Buddha is big, has hairy armpits, and laughs=
=2E"
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=3D20
> _______________________________________________
> Sbcl-help mailing list
> Sbcl-help@...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help

=2D-=20
=3D=3D=3D=3D John Morrison
=3D=3D=3D=3D MAK Technologies Inc.
=3D=3D=3D=3D 10 Fawcett Street, Cambridge, MA 02138
=3D=3D=3D=3D http://www.mak.com/
=3D=3D=3D=3D vox:617-876-8085 x115
=3D=3D=3D=3D fax:617-876-9208
=3D=3D=3D=3D jm@...

This also seems applicable, though not necessarily promising:

        -fno-weak
           Do not use weak symbol support, even if it is provided by the
           linker.  By default, G++ will use weak symbols if they are avail-
           able.  This option exists only for testing, and should not be used
           by end-users; it will result in inferior code and has no benefits.
           This option may be removed in a future release of G++.

Also, see the -z allextract / weakextract option to ld:

  http://www.computerhope.com/unix/uld.htm

Finally, light googling seems to indicate that fakeroot at least has to do 
something strange to deal with weak symbols in conjunction dlopen / dlym 
(which is what SBCL uses to implement sb-alien) -- it may be worth looking 
to see what is involved. If you discover the how of this, I will see if 
SBCL could made smart about it -- though I'm not overly optimistic, since 
there seems to be no dlfoo API to ask "is this weak?".

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."

On Monday 02 May 2005 02:29 am, Nikodemus Siivola wrote:
> This also seems applicable, though not necessarily promising:
>
>         -fno-weak

Empirically, it seems (so far!) -fkeep-inline-functions has done the
trick.  Thanks for all the help and suggestions!

-jm

-- 
==== John Morrison
==== MAK Technologies Inc.
==== 10 Fawcett Street, Cambridge, MA 02138
==== http://www.mak.com/
==== vox:617-876-8085 x115
==== fax:617-876-9208
==== jm@...