This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]