This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH/RFC] Mark __asm__ identifiers as referenced in varasm.c


Whilst compiling mainline on ia64-hp-hpux11.22, I noticed that the
linking of libgomp spews errors from the native linker.

ld: Type mismatch for symbol "gomp_ialias_omp_init_lock"; resolving NOTYPE
symbol (in file .libs/fortran.o) to FUNC symbol (in file .libs/lock.o)

Given that the linker didn't spew these messages for previous releases,
its not unreasonable to consider this a regression :-)


The issue concerns an interaction between identifiers explicitly aliased
by the user using __asm__ and the mechanism used by many backends,
including IA-64/HPUX, for tracking external symbols that need to have
.global and .type entries written to the assembly language output.

A minimal example is:

extern int foo(void) __asm__ ("bar");

int baz()
{
  return foo();
}

Currently, for the above example, mainline doesn't mark any identifiers
as referenced, and therefore on ia64-*-hpux* fails to write out the
lines necessary to silence the native linker...

        .global bar
        .type   bar,@function


The issue is that the DECL_RTL for the function foo is actually
represented internally, as an identifier node denoting "*bar".
However, in varasm.c:assemble_name, when we output identifier
names, we call strip_name_encoding (which removes the asterisk)
before calling "maybe_get_identifer", which fails for the above
case, as the identifier in te hashtable is the raw unstripped
name.

The solution proposed below, is that if the current identifier
"name" lookup fails, and name begins with an asterisk, we then
try looking up the raw identifier and mark that as referenced.


The following patch has been tested on ia64-hp-hpux11.22, with
a full "make bootstrap", all default languages (pity GMP isn't
yet supported), and regression tested with a top-level "make -k
check" with no new failures.  This is sufficient to allow libgomp
to link silently.

Can anyone see any potential problems with this approach?  I'm
happy to test this patch on platforms that folks have concerns
about.  It's just not clear what the intended behaviour of
varasm.c is, and the semantics relied up by other platforms that
make use of mark_referenced.

Thanks in advance,



2006-07-02  Roger Sayle  <roger@eyesopen.com>

	* varasm.c (assemble_name): For identifiers beginning with an
	asterisk, i.e. user-specified identifiers annotated by __asm__,
	mark the identifier as referenced.


Index: varasm.c
===================================================================
*** varasm.c	(revision 115102)
--- varasm.c	(working copy)
*************** assemble_name (FILE *file, const char *n
*** 2091,2096 ****
--- 2091,2103 ----
  	name = IDENTIFIER_POINTER (id);
        gcc_assert (! TREE_CHAIN (id));
      }
+   else if (name[0] == '*')
+     {
+       /* Mark user (__asm__) identifiers as referenced.  */
+       id = maybe_get_identifier (name);
+       if (id)
+ 	mark_referenced (id);
+     }

    assemble_name_raw (file, name);
  }


Roger
--


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]