weak and strong aliases for global data fail

weak and strong aliases for global data fail

[Peter S. Mazinger]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 424 bytes --]

Hello!

Attached tests show a case, when a final binary is OK if 
compiled w/ -fPIC (or -fPIE, it does not have to be ET_DYN, but can be), 
else it fails if using aliases (both weak and strong) for global data.

Sorry for the "big" test cases, I couldn't make them smaller.

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

[-- Attachment #2: Type: TEXT/PLAIN, Size: 945 bytes --]

CC=gcc

RPATH=$(shell pwd)

all: failing_weak_app failing_strong_app

weak_lib:
	$(CC) -fPIC -shared -o libgetopt_weak.so getopt.c

strong_lib:
	$(CC) -D__STRONG__ -fPIC -shared -o libgetopt_strong.so getopt.c

working_weak_app: weak_lib
	$(CC) -Wl,-rpath,$(RPATH) -fPIC -o hidden_weak hidden.c -L. -lgetopt_weak
	./hidden_weak -o out.o hidden.c

failing_weak_app: weak_lib
	$(CC) -Wl,-rpath,$(RPATH) -fno-PIE -o bad_hidden_weak hidden.c -L. -lgetopt_weak
	./bad_hidden_weak -o out.o hidden.c

working_strong_app: strong_lib
	$(CC) -Wl,-rpath,$(RPATH) -fPIC -o hidden_strong hidden.c -L. -lgetopt_strong
	./hidden_strong -o out.o hidden.c

failing_strong_app: strong_lib
	$(CC) -Wl,-rpath,$(RPATH) -fno-PIE -o bad_hidden_strong hidden.c -L. -lgetopt_strong
	./bad_hidden_strong -o out.o hidden.c

clean:
	rm -f out.o hidden_weak bad_hidden_weak hidden_strong bad_hidden_strong libgetopt_weak.so libgetopt_strong.so

[-- Attachment #3: Type: TEXT/PLAIN, Size: 1973 bytes --]

/* parts taken from qemu/dyngen.c */

#include <stdio.h>
#include <stdlib.h>
#include <stdarg.h>

extern char *optarg_test;
extern int optind_test;
extern int getopt_test (int ___argc, char *const *___argv, const char *__shortopts);

enum {
    OUT_GEN_OP,
    OUT_CODE,
    OUT_INDEX_OP,
};

/* load an elf object file */
static int load_object(const char *filename)
{
    return 0;
}

static int gen_file(FILE *outfile, int out_type)
{
    return 0;
}

static void usage(void)
{
    printf("usage: getopt_hidden [-o outfile] [-c] objfile\n"
           "Generate a dynamic code generator from an object file\n"
           "-c     output enum of operations\n"
           "-g     output gen_op_xx() functions\n"
           );
    exit(1);
}

static void __attribute__((noreturn)) __attribute__((format (printf, 1, 2))) error(const char *fmt, ...)
{
    va_list ap;
    va_start(ap, fmt);
    fprintf(stderr, "getopt_hidden: ");
    vfprintf(stderr, fmt, ap);
    fprintf(stderr, "\n");
    va_end(ap);
    exit(1);
}

int main(int argc, char **argv)
{
    int c, out_type;
    const char *filename, *outfilename;
    FILE *outfile;

    outfilename = "out.c";
    out_type = OUT_CODE;
    for(;;) {
        c = getopt_test(argc, argv, "ho:cg");
        if (c == -1)
            break;
        switch(c) {
        case 'h':
            usage();
            break;
        case 'o':
            outfilename = optarg_test;
            break;
        case 'c':
            out_type = OUT_INDEX_OP;
            break;
        case 'g':
            out_type = OUT_GEN_OP;
            break;
        }
    }
    if (optind_test >= argc)
        usage();
    filename = argv[optind_test];
    outfile = fopen(outfilename, "w");
    if (!outfile)
        error("could not open '%s'", outfilename);

    load_object(filename);
    gen_file(outfile, out_type);
    fclose(outfile);
    return 0;
}

[-- Attachment #4: Type: TEXT/PLAIN, Size: 2444 bytes --]

#include <stdio.h>

/* taken from glibc/include/libc-symbols.h */
#define attribute_hidden __attribute__((visibility ("hidden")))

#define weak_alias(name, aliasname) _weak_alias (name, aliasname)
#define _weak_alias(name, aliasname) \
  extern __typeof (name) aliasname __attribute__ ((weak, alias (#name)));

#define strong_alias(name, aliasname) _strong_alias(name, aliasname)
#define _strong_alias(name, aliasname) \
  extern __typeof (name) aliasname __attribute__ ((alias (#name)));

#ifdef __STRONG__
# define do_alias strong_alias
#else
# define do_alias weak_alias
#endif

static const char missing[] = "%s: option requires an argument -- %c\n";
static const char illegal[] = "%s: illegal option -- %c\n";

int __opterr attribute_hidden = 1;
do_alias(__opterr,opterr_test)
int __optind attribute_hidden = 1;
do_alias(__optind,optind_test)
int __optopt attribute_hidden = 0;
do_alias(__optopt,optopt_test)
char *__optarg attribute_hidden = NULL;
do_alias(__optarg,optarg_test)

int getopt_test(int argc, char * const argv[], const char *optstring)
{
	static const char *o;		/* multi opt position */
	register const char *p;
	register const char *s;
	int retval = -1;

	__optopt = 0;
	__optarg = NULL;

	if (!o) {				/* Not in a multi-option arg. */
		if ((__optind >= argc)	/* No more args? */
			|| ((p = argv[__optind]) == NULL) /* Missing? */
			|| (*p != '-')		/* Not an option? */
			|| (!*++p)			/* "-" case? */
			) {
			goto DONE;
		}
		if ((*p == '-') && (p[1] == 0)) { /* "--" case. */
/* 			++optind; */
/* 			goto DONE; */
			goto NEXTOPT;		/* Less code generated... */
		}
		o = p;
	}

	retval = (unsigned char) *o; /* Avoid problems for char val of -1. */

	if ((*o == ':') || !(s = strchr(optstring, *o))) { /* Illegal option? */
		s = illegal;
		retval = '?';
		goto BAD;
	}
	
	if (s[1] == ':') {			/* Option takes an arg? */
		if (o[1]) {					/* No space between option and arg? */
			__optarg = (char *)(o + 1);
			goto NEXTOPT;
		}

		if (__optind + 1 < argc) {	/* Space between option and arg? */
			__optarg = argv[++__optind];
		} else {				/* Out of args! */
			s = missing;
			retval = ':';
		BAD:
			__optopt = *o;
			if (*optstring != ':') {
				retval = '?';
				if (__opterr) {
					fprintf(stderr, s, argv[0], *o);
				}
			}
		}
	}

	if (!*++o) {
	NEXTOPT:
		o = NULL;
		++__optind;
	}
 DONE:
	return retval;
}

Re: weak and strong aliases for global data fail

[Peter S. Mazinger]

On Wed, 17 May 2006, Peter S. Mazinger wrote:

Could anyone tell me if this is a binutils bug (tested 2.16.1/2.16.92) or 
I should send it to the gcc list (tested with 3.4.6). It seems to me that 
it is rather an ld bug.

Thanks, Peter

> Hello!
> 
> Attached tests show a case, when a final binary is OK if 
> compiled w/ -fPIC (or -fPIE, it does not have to be ET_DYN, but can be), 
> else it fails if using aliases (both weak and strong) for global data.
> 
> Sorry for the "big" test cases, I couldn't make them smaller.
> 
> Peter
> 
> 

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: weak and strong aliases for global data fail

[Alan Modra]

On Mon, May 22, 2006 at 10:38:56PM +0200, Peter S. Mazinger wrote:
> On Wed, 17 May 2006, Peter S. Mazinger wrote:
> 
> Could anyone tell me if this is a binutils bug (tested 2.16.1/2.16.92) or 
> I should send it to the gcc list (tested with 3.4.6). It seems to me that 
> it is rather an ld bug.
> 
> Thanks, Peter
> 
> > Hello!
> > 
> > Attached tests show a case, when a final binary is OK if 
> > compiled w/ -fPIC (or -fPIE, it does not have to be ET_DYN, but can be), 
> > else it fails if using aliases (both weak and strong) for global data.
> > 
> > Sorry for the "big" test cases, I couldn't make them smaller.

It's a user bug.  When the linker needs to generate a copy reloc, eg. as
it does for x86 non-PIC code, for a variable like "optind_test" in your
main app, then space is allocated in your main app and initialised from
the shared object.  The main app uses this location for references to
"optind_test", as do references from within the shared lib.  However,
your shared lib is not referencing "optind_test" but an alias stored at
a different location (in the shared lib).

With PIC code the linker can generally dispense with the copy reloc, so
both the main app and the shared lib use the same location.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: weak and strong aliases for global data fail

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

On Wednesday 17 May 2006 07:19, Peter S. Mazinger wrote:
> Attached tests show a case, when a final binary is OK if
> compiled w/ -fPIC (or -fPIE, it does not have to be ET_DYN, but can be),
> else it fails if using aliases (both weak and strong) for global data.
>
> Sorry for the "big" test cases, I couldn't make them smaller.

this is related to this thread on the glibc list:
http://sourceware.org/ml/libc-alpha/2006-04/msg00044.html
http://sourceware.org/ml/libc-alpha/2006-04/msg00048.html
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: weak and strong aliases for global data fail

[Peter S. Mazinger]

On Tue, 23 May 2006, Alan Modra wrote:

> On Mon, May 22, 2006 at 10:38:56PM +0200, Peter S. Mazinger wrote:
> > On Wed, 17 May 2006, Peter S. Mazinger wrote:
> > 
> > Could anyone tell me if this is a binutils bug (tested 2.16.1/2.16.92) or 
> > I should send it to the gcc list (tested with 3.4.6). It seems to me that 
> > it is rather an ld bug.
> > 
> > Thanks, Peter
> > 
> > > Hello!
> > > 
> > > Attached tests show a case, when a final binary is OK if 
> > > compiled w/ -fPIC (or -fPIE, it does not have to be ET_DYN, but can be), 
> > > else it fails if using aliases (both weak and strong) for global data.
> > > 
> > > Sorry for the "big" test cases, I couldn't make them smaller.
> 
> It's a user bug.  When the linker needs to generate a copy reloc, eg. as
> it does for x86 non-PIC code, for a variable like "optind_test" in your
> main app, then space is allocated in your main app and initialised from
> the shared object.  The main app uses this location for references to
> "optind_test", as do references from within the shared lib.  However,
> your shared lib is not referencing "optind_test" but an alias stored at
> a different location (in the shared lib).
> 
> With PIC code the linker can generally dispense with the copy reloc, so
> both the main app and the shared lib use the same location.

The app is a simplified version of getopt() used in glibc, but it happens 
with getopt.c from glibc as well. I have only renamed the internally 
used opt* to __opt* and provided a weak resp. strong alias to the 
externally visible version (also renamed to opt*_test so that it does not 
conflict with the libc provided getopt interface).

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: weak and strong aliases for global data fail

[Peter S. Mazinger]

On Mon, 22 May 2006, Mike Frysinger wrote:

> On Wednesday 17 May 2006 07:19, Peter S. Mazinger wrote:
> > Attached tests show a case, when a final binary is OK if
> > compiled w/ -fPIC (or -fPIE, it does not have to be ET_DYN, but can be),
> > else it fails if using aliases (both weak and strong) for global data.
> >
> > Sorry for the "big" test cases, I couldn't make them smaller.
> 
> this is related to this thread on the glibc list:
> http://sourceware.org/ml/libc-alpha/2006-04/msg00044.html
> http://sourceware.org/ml/libc-alpha/2006-04/msg00048.html
> -mike

That seems to only be related to weak aliases, in my case it happens with
strong aliases as well.

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: weak and strong aliases for global data fail

[Alan Modra]

On Wed, May 24, 2006 at 03:16:26PM +0200, Peter S. Mazinger wrote:
> I have only renamed the internally 
> used opt* to __opt* and provided a weak resp. strong alias to the 
> externally visible version

Symbol aliases in ELF shared libs don't work as you think they should.
This is not a bug in the compiler, linker, or ld.so.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: weak and strong aliases for global data fail

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

On Wednesday 24 May 2006 09:18, Peter S. Mazinger wrote:
> On Mon, 22 May 2006, Mike Frysinger wrote:
> > On Wednesday 17 May 2006 07:19, Peter S. Mazinger wrote:
> > > Attached tests show a case, when a final binary is OK if
> > > compiled w/ -fPIC (or -fPIE, it does not have to be ET_DYN, but can
> > > be), else it fails if using aliases (both weak and strong) for global
> > > data.
> > >
> > > Sorry for the "big" test cases, I couldn't make them smaller.
> >
> > this is related to this thread on the glibc list:
> > http://sourceware.org/ml/libc-alpha/2006-04/msg00044.html
> > http://sourceware.org/ml/libc-alpha/2006-04/msg00048.html
>
> That seems to only be related to weak aliases, in my case it happens with
> strong aliases as well.

read it again ... the bug happens only with strong data aliases, weak data 
aliases work fine
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]