This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C ASSEMBLER_NAME patch
- From: Bob Wilson <bwilson at tensilica dot com>
- To: gkeating at apple dot com
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 24 Jul 2003 13:50:40 -0700
- Subject: Re: C ASSEMBLER_NAME patch
- Organization: Tensilica, Inc.
Geoffrey Keating wrote:
Note that there is one ongoing problem with this patch. It sets the
name of the function the first time that DECL_ASSEMBLER_NAME is
called. If DECL_ASSEMBLER_NAME gets called before the declaration
is fully parsed, the object can get the wrong name. I'm trying to
think of ways to add checking code to detect this...
This is definitely a problem. I'm trying to build glibc for Xtensa (using
version 2.2.5, but I think the relevant code is the same in the latest version).
The sysdeps/unix/sysv/linux/init-first.c file contains the following:
/* The function is called from assembly stubs the compiler can't see. */
static void init (int, char **, char **) __attribute__ ((unused));
static void
init (int argc, char **argv, char **envp)
{
/* CODE DELETED */
}
/* MACROS COPIED FROM include/libc-symbols.h */
/* Define ALIASNAME as a strong alias for NAME. */
# define strong_alias(name, aliasname) _strong_alias(name, aliasname)
# define _strong_alias(name, aliasname) \
extern __typeof (name) aliasname __attribute__ ((alias (#name)));
strong_alias (init, _init);
There are really two problems here.
The first problem is that the name for "init" is set while parsing the prototype
and the STATIC flag is not yet set, so that the function is labeled "init.0".
If I remove the prototype for init, the name doesn't get changed. I thought
that perhaps removing the attribute from the prototype would make a difference,
but it doesn't.
The second problem is that the aliased definition doesn't use the modified name.
GCC emits the following:
.type init.0, @function
init.0:
[ instructions deleted ]
.size init.0, .-init.0
.global _init
.set _init,init
The last line should be ".set _init,init.0". I think that fixing this second
problem would fix my glibc build, but it seems that the first problem ought to
be fixed as well, since otherwise your patch isn't really doing what it's
supposed to do.
--Bob