On Mon, Feb 17, 2003 at 10:58:21PM +0900, GOTO Masanori wrote: > Hi Guido, > Thanks for your explanation. > > At Sun, 16 Feb 2003 23:32:42 +0100, > Guido Guenther wrote: > > I'm trying to explain how I understand these issues, but it might not be > > correct: > > > > On Mon, Feb 17, 2003 at 12:49:44AM +0900, GOTO Masanori wrote: > > > 1. Why is __fixunsdfdi appeared, on the contrary why is not __fixdfdi > > > appeared > > gcc does the double -> signed long long conversion inline but uses a > > function call for the unsigned conversion. > > Hmm, I feel it's strange feature... There are no need to distinguish > between signed and unsigned. Is it gcc bug?
The inlining is just based on cost. One of those operations is cheaper than the other on 386 hardware. > > For example: > > /usr/bin/nm __udivdi3 > > /usr/bin/nm __umoddi3 > > /usr/bin/strip __ucmpdi2 > > /usr/bin/strip __udivdi3 > > I'm sorry, but I can't understand what you mean... You mean that a binary > has _udivdi3 or __umoddi3 and then drops its symbol with strip? No, strip was just an example. And it's been rebuilt on i386 since that measurement was made so you can't see it any more. But it goes like this: libbfd.so is built it contains __udivdi3 strip is linked to -lbfd it needs __udivdi3 it gets __udivdi3 from libbfd.so libbfd.so is recompiled by GCC 3.2 it no longer provides __udivdi3 Until strip is recompiled, strip doesn't run. > > > Well, dcgui (#179781) should be fixed with the latest glibc and gcc > > > environment. Moreover, if binaries on woody/sarge works well, then I > > > think we should not add this compat-patch even if sid binaries causes > > > such unresolved symbol bug. > > No. We only add symbols for the woody->sarge transition. > > So, is it debian specific patch? Uh, I don't think it should be. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer