GCC Bugzilla Bug 32219

following testcase causes gpf on i386.

$ cat exe.c
extern void f() __attribute__((weak,visibility("hidden")));
extern int puts( char const* );
int main()
{
        f ? f() : puts( "f == null, skipped." );
        return 0;
}

$ gcc exe.c -fPIE --save-temps -m32 -O1 && ./a.out
Segmentation fault

this fails on i386 with gcc 3.4.5, 4.0, 4.1 and 4.2 (4.3 not tested).
x86_64 and ppc works fine, so it looks like a ix86 target bug.

btw, imho the weak+hidden is not a valid combination.
such symbol can't be resolved in runtime because it doesn't exist
in elf rel.plt/rel.dyn tables. it can be resolved only during
linking several objects into one piece (e.g. exec/shlib),
but in such case the weak+hidden behaves like plain hidden.

f always will bind local ...
Also you should be using -PIE when linking.

(In reply to comment #2)

> Also you should be using -PIE when linking.

hmm, it doesn't work with int main();

$ gcc -s main.c -fpie -Wl,-pie
/usr/bin/ld: /usr/lib64/crt1.o: relocation R_X86_64_32S against
`__libc_csu_fini' can not be used when making a shared object;
 recompile with -fPIC
/usr/lib64/crt1.o: could not read symbols: Bad value
collect2: ld returned 1 exit status

huh, glibc bug, linker bug?

(In reply to comment #2)
> f always will bind local ...

so, should gcc reject weak attribute in this (hidden visibility) case?

(In reply to comment #3)
> (In reply to comment #2)
> 
> > Also you should be using -PIE when linking.
> 
> hmm, it doesn't work with int main();
> 
> $ gcc -s main.c -fpie -Wl,-pie
> /usr/bin/ld: /usr/lib64/crt1.o: relocation R_X86_64_32S against
> `__libc_csu_fini' can not be used when making a shared object;
>  recompile with -fPIC
> /usr/lib64/crt1.o: could not read symbols: Bad value
> collect2: ld returned 1 exit status
> 
> huh, glibc bug, linker bug?

with gcc-4.2.3 and binutils-2.18.50.0.4 it links fine.

Weak and hidden aren't really compatible. Linker should enforce it.
I opened a linker bug:

http://sourceware.org/bugzilla/show_bug.cgi?id=5789

As for gcc, I think it is OK since it is a user error and linker
should issue an error. Besides, gcc doesn't know if the .o
file will be used for PIE/shared library or normal executable.
The runtime error only happens with PIE/shared library, not
normal executable.

It is a compiler bug after all. From:

http://groups.google.com/group/generic-abi/browse_thread/thread/4364eb484397ebe0

A hidden symbol must be defined in the same component, *if it is  
defined at all*. That last part is the key to the issue. In the case  
of a WEAK HIDDEN UNDEF symbol, it is possible for the symbol to remain  
undefined (or, looked at another way, it is possible for the symbol to  
be defined at link time as an absolute symbol with value 0). I agree  
with Daniel; the compiler should be aware of this possibility and  
generate code that will not require a dynamic relocation for this case.

For a weak and hidden symbol, it is bound local only if PIC is false or
it is used for branch. Otherwise, it should be treated with default
visibility.

What's the status of this bug ?
The same things can happen in libraries with fpic