From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Wed, 26 Apr 2006 03:12:21 +0100
From: Derek Fawcus <dfawcus@cisco.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] impressive
Message-ID: <20060426031221.D22520@mrwint.cisco.com>
References: <444D3701.50303@lanl.gov> <20060425031523.N21356@mrwint.cisco.com>
	<20060425022329.GF25096@submarine>
	<20060425033704.O21356@mrwint.cisco.com>
	<20060425035117.GB25952@submarine>
	<20060425091701.Q21356@mrwint.cisco.com>
	<20060425175302.GH25096@submarine>
	<20060426021131.C22520@mrwint.cisco.com>
	<20060426011933.GA20406@submarine>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <20060426011933.GA20406@submarine>;
	from rvs@sun.com on Tue, Apr 25, 2006 at 06:19:33PM -0700
Topicbox-Message-UUID: 46389904-ead1-11e9-9d60-3106f5b1d025

On Tue, Apr 25, 2006 at 06:19:33PM -0700, Roman Shaposhnick wrote:
> On Wed, Apr 26, 2006 at 02:11:32AM +0100, Derek Fawcus wrote:
> > Anyway,  I found the culprit - libgcc has modules compiled with exception
> > handling sections;  __udivdi3 and __umoddi3 get pulled from there.
>
>   Well, how exactly does it relate to the original topic where we
>   were discussing glibc ? libgcc is not part of glibc.

It relates to the sub thread where I linked the program with dietlibc
rather than with glibc,  got a more sensible sized program,  and was
then trying to figure out where the .eh_frame section came from.

The compiler I'm using does not generate .eh_frame sections by default,
so neither the testit.o file (compiled from the posted C source) nor
the input .o files from dietlibc contain such sections.

Hence my assertion that it was something the linker was doing,  I had
forgotten about the existance of libgcc.  Now that I know where it is
coming from,  I can ignore it.

While the info you supplied was interesting,  it did not directly relate
to what I was trying to figure out.

> > Mind there is a separate libgcc.a and libgcc_eh.a;  I'm not sure what
> > the difference is supposed to be (the latter is about half the size).
>
>   libgcc.a	-	Support routines, not including EH
>   libgcc_eh.a	-	EH support routines
>   libgcc_s.so	-	Support routines, including EH

Well maybe Suse messed up,  or the compiler is simply old enought to be
doing stuff differently.

This machine does not have the .so,  the _eh.a contains a bunch of unwind
routines,  and the objects within libgcc.a have been compiled to include
.eh_frame sections. (GCC 3.3.3)

However the mips64 crosscompiler version of gcc 3.4.4 that I compiled up,
only has libgcc.a,  and it also has .eh_frame sections in the same objects.
Looking at the C source for them,  there would not appear to be any good
reason for these to have EH info - they don't call anything else.

So it just looks like GCC is always compiling the div/mod helper routines
with .eh_frame sections requested.

DF