This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Small footprint on Embedded system
- From: Jeff Sturm <jsturm at one-point dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gcj mail list <java at gcc dot gnu dot org>
- Date: Tue, 24 Sep 2002 19:20:50 -0400 (EDT)
- Subject: Re: Small footprint on Embedded system
On 24 Sep 2002, Tom Tromey wrote:
> Pete> My question is, what the @#$% is my question? Oh yeah, am I
> Pete> leaving out some build step that requires the copying of the .so
> Pete> files? Is there a way to recompile gcc/gcj to greatly reduce
> Pete> the size of the .so files?
>
> This topic comes up periodically. We have some ideas for how to
> reduce the footprint of libgcj, but so far nobody has implemented
> them.
Speaking of that... has anyone ever looked at the dwarf2 output of gcj?
It doesn't affect runtime footprint, but much of the bloated size of
libgcj.so has to do with emitting debug info for every class referenced
directly or indirectly from a source file.
I tried the quick hack below, but gdb didn't handle it well.
Index: class.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/java/class.c,v
retrieving revision 1.135
diff -u -p -r1.135 class.c
--- class.c 21 Sep 2002 02:19:44 -0000 1.135
+++ class.c 24 Sep 2002 23:19:41 -0000
@@ -353,7 +353,10 @@ lookup_class (name)
{
tree decl = IDENTIFIER_CLASS_VALUE (name);
if (decl == NULL_TREE)
- decl = push_class (make_class (), name);
+ {
+ decl = push_class (make_class (), name);
+ TYPE_DECL_SUPPRESS_DEBUG (decl) = 1;
+ }
return TREE_TYPE (decl);
}