At Mon, 17 Feb 2003 11:12:11 -0500, Daniel Jacobowitz wrote: > 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.
Ah, exactly. In many case calling function consumes more costs than inlining, but __fixunsdfdi is larger than __fixdfdi - so inlining __fixunsdfdi causes to increase binary size, so it's not bug, it's intentional. > > > 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. Thanks, I finally understand this story. > > > > 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. Well, we leave it to Guido's decision... Thanks, -- gotom
