[M3commit] CVS Update: cm3

Jay K jay.krell at cornell.edu
Mon May 17 14:17:26 CEST 2010


Index: parse.c
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v
retrieving revision 1.140
diff -u -r1.140 parse.c
--- parse.c    17 May 2010 08:48:17 -0000    1.140
+++ parse.c    17 May 2010 12:10:07 -0000
@@ -3416,17 +3416,24 @@
   MTYPE2  (return_type, ret_type);
   LEVEL   (lev);
   CC      (cc);
-  UNUSED_BOOLEAN (exported);
+  BOOLEAN (exported);
   PROC    (parent);
   PROC    (p);
 
   tree resultdecl;
   tree parm_block = make_node (BLOCK);
   tree top_block  = make_node (BLOCK);
+  
+  /* Level must be positive and nested functions
+   * are never exported.
+   */
+  gcc_assert(lev>= 0);
+  gcc_assert(lev == 0 || !exported);
 
   if (option_procs_trace)
-    fprintf(stderr, "  procedure %s nparams 0x%lx rettype 0x%x\n", n, n_params,
-            ret_type);
+    fprintf(stderr,
+            "  procedure %s nparams 0x%lx rettype 0x%x lev %u exported %u\n",
+            n, n_params, ret_type, (unsigned)lev, (unsigned)exported);
 
 #if M3CG_ADAPT_RETURN_TYPE
   /** 4/30/96 -- WKK -- It seems gcc can't hack small return values... */
@@ -3443,7 +3450,28 @@
 
   DECL_NAME (p) = get_identifier (n);
   TREE_STATIC (p) = 1;
-  TREE_PUBLIC (p) = (lev == 0); /* exported */
+
+  /* TREE_PUBLIC (p) should be 'exported', but that fails to keep any
+   * implementation of nonexported functions, even with TREE_ADDRESSABLE(p) = 1
+   */
+  TREE_PUBLIC (p) = (lev == 0);
+  if (exported)
+  {
+   /* We really want to use VISIBILITY_PROTECTED here but we can't for
+    * multiple reasons. It doesn't work on Darwin.
+    * Even on Linux, we still reference symbols indirectly via GOT and get
+    * an error. I don't know why.
+    *
+    * More general problem is we don't know in import_procedure
+    * what we are importing from other modules within the same shared
+    * object, vs. from other shared objects.
+    */
+    DECL_VISIBILITY (p) = VISIBILITY_DEFAULT;
+  }
+  else
+  {
+    DECL_VISIBILITY (p) = VISIBILITY_HIDDEN;
+  }
   DECL_CONTEXT (p) = parent;
   TREE_TYPE (p) = build_function_type (return_type, NULL_TREE);
   DECL_MODE (p) = FUNCTION_MODE;
@@ -5095,6 +5123,7 @@
 static void
 m3cg_fetch_and_xor (void) { m3cg_fetch_and_op (BUILT_IN_FETCH_AND_XOR_N); }
 
+#if 0
 static void
 m3cg_lock_test_and_set (void)
 {
@@ -5143,6 +5172,7 @@
  incompatible:
   fatal_error ("incompatible type for argument to atomic op");
 }
+#endif
 
 /*----------------------------------------------------------- M3CG parser ---*/
 


If it wasn't for the big comment I put in, the if/else could just use ternary operator.
I'm still not satisfied here, but this is a small improvement.

 - Jay

----------------------------------------
> Date: Mon, 17 May 2010 14:13:03 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
>
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/05/17 14:13:03
>
> Modified files:
> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c
>
> Log message:
> Only export exported functions.
> And really, I'd like to stop referencing non-imported functions
> via GOT, but I can't get it to work.
>
> Work on: Don't export everthing from shared objects.
> Ideally -- only stuff in *.i3 files, and with "Interface" not "interface".
> Work on: Don't go through PLT/GOT for stuff defined in same module (which
> includes stuff exported or not).
>
> Linux/x86:
> before:
> jay at xlin2:~$ readelf -s /cm3/lib/libm3core.so | grep -i expand |wc -l
> 18
> jay at xlin2:~$ readelf -s /cm3/lib/libm3core.so | grep -v UND |wc -l
> 4564
>
> after:
> jay at xlin2:~$ readelf -s /cm3/lib/libm3core.so | grep -i expand |wc -l
> 9
> jay at xlin2:~$ readelf -s /cm3/lib/libm3core.so | grep -v UND |wc -l
> 4218
>
> (everything is listed twice, it turns out)
>
> ("expand" I just happen to know is often part of unexported function names,
> when there are home-grown growable arrays present)
>
> MacOSX/x86:
>
> before:
> jbook2:m3cg jay$ otool -Tv /cm3.x86/lib/libm3core.dylib | wc -l
> 1852
> jbook2:m3cg jay$ otool -Tv /cm3.x86/lib/libm3core.dylib | grep -i expand | wc -l
> 9
>
> after:
>
> jbook2:m3cg jay$ otool -Tv /cm3.x86/lib/libm3core.dylib | grep -i expand
> jbook2:m3cg jay$ otool -Tv /cm3.x86/lib/libm3core.dylib | wc -l
> 1506
>
> There is possibly more to be done here, but this is a good start.
>
> Gcc doesn't seem to support what we want, unless we communicate more information
> around that we have, and even then I'm not sure.
>
> In particular, anything in the same shared object, we don't want to refer
> to via the GOT/PLT. We don't compile "shared objects" though, we compile
> individual source files, without knowledge as to what other source files they
> will be linked to.
>
> see (from me):
> http://gcc.gnu.org/ml/gcc-help/2010-05/msg00148.html
>
> (more useful:
> readelf -s /cm3/lib/libm3core.so | grep -v UND | grep GLOBAL | awk '{print $8}' | sort |uniq |wc -l
> )
>
 		 	   		  


More information about the M3commit mailing list