This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix unwinding through SA_ONSTACK signal frames on IA-64
On Thu, Dec 18, 2003 at 01:04:48PM -0800, David Mosberger wrote:
> >>>>> On Thu, 18 Dec 2003 15:24:44 -0500, Jakub Jelinek <jakub@redhat.com> said:
>
> Jakub> 2) libgcc_s is linked to all C++ programs and shared
> Jakub> libraries. Your libunwind+libgcc_s.so without unwind-ia64.o
> Jakub> is uncomparably bigger than libgcc_s.so with unwind-ia64.o (4
> Jakub> times bigger RE segments, 5 times bigger RW segment, 10 times
> Jakub> more dynamic relocations).
>
> That's not really a useful comparison. With the built-in unwinder,
> you'll link against gcc_eh which will pull in code into the
> executable, with all the size disadvantages and compatibility problems
> that entails.
You mean those < 1% of executables which are using exceptions/cleanups,
but are C only? See my recent mail to binutils@sources on what can be done
about it. Until recently there were no such binaries.
Just curious, what does GCC --enable-libunwind-exceptions do in that case
ATM? Link every single C binary with shared libunwind even if it never uses
exceptions/cleanups?
> Furthermore, libunwind contains two versions of the source code: one
> compiled for generic use and one for local-only unwinding. The
> local-only version is used for GCC exception handling which is smaller
> (and faster) and should have fewer dynamic relocs than the generic
> version. Thus, your numbers are inflated by at least a factor of two.
> If size/dynamic relocs is a primary concern, I'm sure it's something
> that can be improved on even further (but like I said, I don't think
> the situation is unreasonable at the moment).
I certainly don't see any configure options to build libunwind for
local-only unwinding. If there is some, I'm sorry. Still, it is
bigger, but as Ulrich already pointed out, point 1) is more important
than 2).
If I understand it right, handling register rotation in unwind-ia64.c
should be a matter of writing one very small inline function and using
it in 2 places.
Jakub