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
