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]

Re: [discuss] Re: [patches] Re: x86_64 frame unwind info


On Thu, Oct 18, 2001 at 01:58:29PM -0400, Geert Bosch wrote:
> Why would you need to make it part of the x86-64 ABI? (It definately must
> not be.) There is no requirement that this routine be callable by all 
> programs on x86-64.  Any program that requires the functionality of 
> walking the stack, can either implement the algorithm itself, 
> or use another implementation.
> 
> Could you explain why you'd think libgcc would need to be part of the ABI?

If the unwind tables can change all the time (as Richard claims), then
they could be only accessed using standard libraries. This would be 
currently libgcc or a new to be invented library.

If this would true -- the unwind tables are a private property of some
runtime library -- then all the parts in the ABI describing them
could be removed.

It would be possible to store them twice: once in the private format
used by gcc, once in the public format described in the ABI and possibly
another time in dwarf2 for the debugger. Giving the large space overhead
of unwind tables I think having 2 or even 3 copies of them is not
an option.

[Even if you would spec it this way I could surely tell you that 
users would not accept it; e.g. for the SuSE distribution if there was
a way to shrink all executables by 10% by getting rid of one copy
of redundant information we would very likely go it because CD/DVD
space is a critical resource]

So there are conflicting goals here:
[1] gcc people want to keep their options for changing the unwind table 
in the future open by making them private property of libgcc.
[2] abi wants a single defined frozen format that can be used by 
all vendors. 
And
[3] users don't want multiple copies.

If you accepted [1] then libgcc or something that interfaced to libgcc
(libgcc in disguise) would need to be part of the ABI. Supporting other 
vendors would not work unless they commit to go with any possible change 
in the gcc format.

A solution either needs to change the ABI or make gcc use a fixed frozen
format.

-Andi


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