[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