alias of hidden function

alias of hidden function

[Jack Howarth]

   On x86_64-apple-darwin10, we fail the lto testcase...

/sw/src/fink.build/gcc46-4.5.999-20100508/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc46-4.5.999-20100508/darwin_objdir/gcc/ -O0 -fwhopr -c -o c_lto_20081222_1.o
/sw/src/fink.build/gcc46-4.5.999-20100508/gcc-4.6-20100508/gcc/testsuite/gcc.dg/lto/20081222_1.c
/sw/src/fink.build/gcc46-4.5.999-20100508/gcc-4.6-20100508/gcc/testsuite/gcc.dg/lto/20081222_1.c:14:21:
error: only weak aliases are supported in this configuration

The test case is..

cat 20081222_0.h
int x();

cat 20081222_1.c
#include "20081222_0.h"

/* Actually, call "x" "INT_X", and make it hidden.  */
extern __typeof (x) x
      __asm__ ("INT_x")
      __attribute__ (( __visibility__ ("hidden")));

int x ()
{
 return 7;
}

/* Make an externally-visible symbol "X" that's an alias for INT_x.  */
extern __typeof (x) EXT_x
      __asm__ ("x")
      __attribute__ ((__alias__ ("INT_x")));

This compiles fine under Fedora 10 linux...

gcc -O0 -c -o c_lto_20081222_1.o 20081222_1.c

where as on x86_64-apple-darwin10 we get...

gcc -O0 -c -o c_lto_20081222_1.o 20081222_1.c
20081222_1.c:16: error: only weak aliases are supported in this configuration

Changing the last line of 20081222_1.c to "__attribute__ ((weak, __visibility__ ("hidden")));"
changes the error on darwin to...

gcc -O0 -c -o c_lto_20081222_1.o 20081222_1.c
20081222_1.c:16: error: ‘EXT_x’ aliased to undefined symbol ‘INT_x’

The fact that we pass testsuite/g++.old-deja/g++.ext/attrib5.C...

// { dg-do run { xfail alpha*-dec-osf* i?86-pc-cygwin } }
// Test that attributes weak and alias coexist.
// { dg-require-weak "" }
// { dg-require-alias "" }

extern "C" {
  void _f () { }
  void f () __attribute__((weak, alias ("_f")));
}

int main ()
{
  f ();
}

would seem to suggest that darwin has functional weak alias support.
Are there any standards in effect which would dictate that
the alias of a hidden function is valid? I find the logic of
that a bit worrisome and wonder if it is really defined behavior.
Thanks in advance for any comments.
             Jack

Re: alias of hidden function

[Dave Korn]

On 10/05/2010 14:30, Jack Howarth wrote:

> Are there any standards in effect which would dictate that
> the alias of a hidden function is valid? 

  Visiblity doesn't apply to functions, it applies to symbols.  Symbols are
textual names with a linked value that exist in object files.  The compiler
emits assembler source that directs the assembler to output an object file
containing the code for the function x, and for two symbols that both have the
value of the address of x (but neither of which is actually called "x").  The
visibility of one of these symbols is set to hidden; the visibility of the
other is not.  It is not the function that is hidden, only (one of the two)
symbols pointing at that function.

  (Also, it's not hidden from the compiler, or indeed the static linker, but
only from the runtime loader, in any case.)

    cheers,
      DaveK

Re: alias of hidden function

[Jack Howarth]

On Mon, May 10, 2010 at 04:17:26PM +0100, Dave Korn wrote:
> On 10/05/2010 14:30, Jack Howarth wrote:
> 
> > Are there any standards in effect which would dictate that
> > the alias of a hidden function is valid? 
> 
>   Visiblity doesn't apply to functions, it applies to symbols.  Symbols are
> textual names with a linked value that exist in object files.  The compiler
> emits assembler source that directs the assembler to output an object file
> containing the code for the function x, and for two symbols that both have the
> value of the address of x (but neither of which is actually called "x").  The
> visibility of one of these symbols is set to hidden; the visibility of the
> other is not.  It is not the function that is hidden, only (one of the two)
> symbols pointing at that function.
> 
>   (Also, it's not hidden from the compiler, or indeed the static linker, but
> only from the runtime loader, in any case.)
> 
>     cheers,
>       DaveK

Dave,
   The darwin linker maintainer suggested that the alias attribute might
not be supported in their gcc. Their on-line documentation seems to be
silent on the issue. However I do notice the following on powerpc-apple-darwin9...

gcc -O0 -c -o c_lto_20081222_1.o 20081222_1.c
20081222_1.c:16: error: 'EXT_x' aliased to undefined symbol 'INT_x'
20081222_1.c:16: warning: alias definitions not supported in Mach-O; ignored

gcc-4.2 -O0 -c -o c_lto_20081222_1.o 20081222_1.c
20081222_1.c:16: error: 'EXT_x' aliased to undefined symbol 'INT_x'

So it appears that may be the case for the older gcc 4.0.1 compiler in
darwin but they would have appeared to have added support in the newer
Apple gcc 4.2.1 compiler.
    Interestingly, with the alias marked as weak, I get...

 gcc-4.2 -O0 -v -c -o c_lto_20081222_1.o 20081222_1.c
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: /var/tmp/gcc_42/gcc_42-5574~1/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/usr/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-gxx-include-dir=/usr/include/c++/4.0.0 --program-prefix= --host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5574)
 /usr/libexec/gcc/powerpc-apple-darwin9/4.2.1/cc1 -quiet -v -D__DYNAMIC__ 20081222_1.c -fPIC -quiet -dumpbase 20081222_1.c -mmacosx-version-min=10.5.8 -auxbase-strip c_lto_20081222_1.o -O0 -version -o /var/tmp//ccfwMpMN.s
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/lib/gcc/powerpc-apple-darwin9/4.2.1/../../../../powerpc-apple-darwin9/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/powerpc-apple-darwin9/4.2.1/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
GNU C version 4.2.1 (Apple Inc. build 5574) (powerpc-apple-darwin9)
        compiled by GNU C version 4.2.1 (Apple Inc. build 5574).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c54eb6db87684e4d5a5bb9ad02c2b2c4
20081222_1.c:16: error: 'EXT_x' aliased to undefined symbol 'INT_x'

which I assume means this error message is coming from the compiler and not
the linker. So it still unclear to me if this is a bug in the alias attribute
support in gcc for darwin or in darwin's assembler or linker.
           Jack

Re: alias of hidden function

[Dave Korn]

On 10/05/2010 16:19, Jack Howarth wrote:

> Compiler executable checksum: c54eb6db87684e4d5a5bb9ad02c2b2c4
> 20081222_1.c:16: error: 'EXT_x' aliased to undefined symbol 'INT_x'
> 
> which I assume means this error message is coming from the compiler and not
> the linker. So it still unclear to me if this is a bug in the alias attribute
> support in gcc for darwin or in darwin's assembler or linker.

  I get the same on COFF, so it isn't the assembler or linker, and visibility
is a red herring, therefore it must be a problem in the compiler's
understanding of aliases; QED, I would have thought.  Haven't had time to dig
deeper yet.  (On COFF with GAS, the compiler uses a .set directive to
implement the alias.)

  The error comes from finish_aliases_1 in varasm.c, where it is suppressed in
the case of a weakref.  I don't know why.

    cheers,
      DaveK

Re: alias of hidden function

[Dave Korn]

On 10/05/2010 17:16, Dave Korn wrote:
> On 10/05/2010 16:19, Jack Howarth wrote:
> 
>> Compiler executable checksum: c54eb6db87684e4d5a5bb9ad02c2b2c4
>> 20081222_1.c:16: error: 'EXT_x' aliased to undefined symbol 'INT_x'

>   The error comes from finish_aliases_1 in varasm.c, where it is suppressed in
> the case of a weakref.  I don't know why.

  Well, I can infer that it would be because it's legitimate not to define a
weak symbol.  I guess the problem might be that find_decl_and_mark_needed when
called on EXT_x gets confused by the combination of an asm decl as well as an
alias maybe?

    cheers,
      DaveK

Re: alias of hidden function

[Jack Howarth]

On Mon, May 10, 2010 at 05:20:22PM +0100, Dave Korn wrote:
> On 10/05/2010 17:16, Dave Korn wrote:
> > On 10/05/2010 16:19, Jack Howarth wrote:
> > 
> >> Compiler executable checksum: c54eb6db87684e4d5a5bb9ad02c2b2c4
> >> 20081222_1.c:16: error: 'EXT_x' aliased to undefined symbol 'INT_x'
> 
> >   The error comes from finish_aliases_1 in varasm.c, where it is suppressed in
> > the case of a weakref.  I don't know why.
> 
>   Well, I can infer that it would be because it's legitimate not to define a
> weak symbol.  I guess the problem might be that find_decl_and_mark_needed when
> called on EXT_x gets confused by the combination of an asm decl as well as an
> alias maybe?
> 
>     cheers,
>       DaveK

Dave,
   When I pointed out to the darwin linker maintainer that their gcc 4.0.1
compiler produced an error message...

> gcc-4.0 -O0 -c -o c_lto_20081222_1.o 20081222_1.c
> 20081222_1.c:16: error: 'EXT_x' aliased to undefined symbol 'INT_x'
> 20081222_1.c:16: warning: alias definitions not supported in Mach-O;
> ignored

but that for the newer Apple gcc 4.2.1 compiler (and FSF gcc) we don't
get the 'warning: alias definitions not supported in Mach-O' warning,
his reply was...

--------------------------------------------------------------------------

My understanding is the mach-o file format does not have a way to encode
aliases.

The weak alias case works sometimes, because the compiler just ignores the
alias part and just makes a weak def of the function with the aliased name.

---------------------------------------------------------------------------

I also found http://gcc.gnu.org/ml/gcc/2005-12/msg00009.html where Geoffrey Keating
indicates that Mach-O doesn't support aliases in the object file at all.
          Jack
ps I am still trying to find the patch that removed the warning "alias definitions not
upported in Mach-O" from Apple's gcc since that might have some useful comments
on the current situation.