Re: libunwind in unstable

[Matthias Klose <doko@cs.tu-berlin.de>]

David Mosberger writes:
> >>>>> On Tue, 23 Nov 2004 09:27:52 +0100, Matthias Klose <doko@cs.tu-berlin.de> said:
> 
>   Matthias> Is the patch in #278836 a prerequisite for the above
>   Matthias> changes, or can it be done without it?
> 
> If the gas-patch isn't applied, you run the risk of getting wrong
> unwind-info into object-files.  For GCC proper, that shouldn't matter
> but it could be an issue for the libraries generated by GCC.  It's not
> all that common to get frame-pointer-relative info on ia64, which is
> the only case that's affected, so I suppose we could check the
> affected libraries for such info (assuming we can generate a list of
> affected libraries).

ok, raising the severity to serious.

>   Matthias> Same question for #278837.
> 
> The hunk for file ptl/sysdeps/unix/sysv/linux/ia64/pt-initfini.c is definitely
> needed.  The other hunks are needed only when building glibc with a GCC which
> has a dependency on -lunwind.

so this one is dependent on #278837, but independent of #278835.

>   Matthias> As an alternative, revert the libunwind patch.
> 
> Which patch are you referring to here?

the patch, which introduced the -lunwind support in GCC-3.4.3.

> My main concern is to ensure that the toolchain generates correct
> unwind-info.  That question is independent of whether or not -lunwind
> is used by GCC, so I hope we can achieve the former even if the latter
> is out of scope at the moment.

>From my point of view we can get around with it by including the
libunwind shared library in libgcc1 for the sarge release. I'm worried
about the version skew of the unwind lib ib 0.98.3 and GCC-3.4.3.
There's one additional library in libunwind.

	Matthias