Re: _GLOBAL_$F$

["Steve deRosier" <sderosier at vari-lite dot com>]

Nik,

A while ago we experimented with moving from our MRI tool set to GCC.  I
converted a number of our embedded projects running on 68332 and the 68040,
and came up with much the same problem as you--size.  One of our projects
went from 80k to about 160k!

Here is the good news, I was able to significantly shrink the size by
playing with the optimizations.  First go through all of the different
optimization levels -O1..-O4 & -Os.  Contrary to what you may expect -Os
does not always produce the smallest size executable.  I found that
different projects would have the smallest sized produced with different
optimization levels.  Second, since we don't use the exception processing
stuff, I removed them by setting -fno-rtti and -fno-exceptions.  By finding
the optimal optimization level + those two extra arguments I was able to
shrink the size to 97k.  That's where I stopped (the project was an
experiment and once I proved we could move to GCC if we wanted then it
became low priority to actually do it).  I suspect that if I recompiled the
Newlib libraries (or replaced them completely with hand written ones) that I
was using with better optimization and using those two arguments I would be
able to get even closer to the original size.  I figure I would end up about
85-90k which would be close enough for us.

There was some discussion on one of the lists that I belong to as to why GCC
makes code that is more bloated than what the MRI outputs.  The eventual
answer to that basically boiled down to no one has maintained the m68k code
for a long time, other than to make sure that new GCC features (and new
additions to the m68k family) don't break it.  In other words no one has
optimized the output of GCC for the m68k in a very long time.  Very sad
considering that one of the m68k was actually the first chip GCC targeted.

As far as your _GLOBAL_$F$  I'm assuming that it has something to do with
the exception handling and much of it should go away using the right options
but I don't really know exactly what they are (and I don't have time to pour
through GCC source to figure it out, sorry).

I hope this helps some.

- Steve

----------
>From: Nik Ilijic <niki@pacomsystems.com>
>To: crossgcc@sourceware.cygnus.com
>Subject: _GLOBAL_$F$
>Date: Fri, Oct 19, 2001, 1:01 AM
>

> I've recently started experimenting with GCC & associated tools with the
> intent of replacing our existing SDS development system.
>
> I'm working with gcc ver 2.95.3 on a linux box, compiling to an embedded
> 68360 target (m68k-coff target).  So far I have managed to compile & link my
> project, but have come across a problem with the size of the binary.
>
> the entire code (.text) and .data sections are about twice the size as I get
> with the SDS toolset.  After examining the map file produced by the linker,
> the biggest blowout seems to be in the data section and it is caused by
> these _GLOBAL_$F$ references (see section of map file below).
>
> What are these _GLOBAL_$F$'s and how do I get rid of them to reduce my
> code/data size so that it fits into the rom & ram.
>
> Thanks in advance,
> Nik Ilijic
> Development Engineer
> Pacom Systems Pty. Ltd.
> Australia
>
>
> -------------------------------
>
>  .data          0x00c2c61c     0x1c14 port/applic/aip/aip.obj
>                 0x00c2c658                snmpIfList
>                 0x00c2c628                aipPtrs
>                 0x00c2e098                AipDlink::_GLOBAL_$F$(void)
>                 0x00c2d4f0                AipSess::_GLOBAL_$F$(short,
> unsigned char *, unsigned char)
>                 0x00c2c688                snmpIfNumber
>                 0x00c2c68c                _GLOBAL_$F$aipPtrs
>  .data          0x00c2e230      0xd88 port/applic/aip/snmp/snmp.obj
>                 0x00c2ee26                mib_entries
>                 0x00c2ee64
> Aip::_GLOBAL_$F$Sif_match(SNB_ENTRY *,...)
>                 0x00c2ee2a                tabtab
>                 0x00c2ee42                _GLOBAL_$F$mib
>                 0x00c2e8e0                mib
>                 0x00c2e23c                Aip::_GLOBAL_$F$SnInit(void)
>                 0x00c2e678                _GLOBAL_$F$mib_prefix
>                 0x00c2e830                Aip::_GLOBAL_$F$GetMib(O_ID *)
>                 0x00c2e673                mib_prefix
>
>
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com