Re: Processed: reassign 179781 to glibc, severity of 179781 is serious, merging 179781 178645

[GOTO Masanori <gotom@debian.or.jp>]

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