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

[Geert Bosch <bosch at gnat dot com>]

On Thu, 18 Oct 2001, Andi Kleen wrote:
  
  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 it would be true that the format can change all the time. For EH purposes, 
such a library has been defined as part of the x86-64 ABI.
  
  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.

Currently there is a description that unwind tables are present in
the .eh_section in DWARF format. Now of course the DWARF standard is
quite big, and it is not to be expected or necessary that *all* 
DWARF readers can understand *all* DWARF writers all the time. 
For example, GDB might only recognize the subset required to work 
fine with code generated by some standard compilers, such as GCC.

On the other hand, since there is a system-provided EH library 
implementing the necessary functions for exception handling, the compiler
has to generate information which is consistent with what the EH library
expects and it is necessary that this format be stable.
  
  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.

No, this seems a bit ridiculous and I don't see why the one public format
would not be enough.
  
  [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]

Right, and this is also one of the reasons why it might be decided during
further development of the x86-64 development system that it is necessary
to specify some additional DWARF codes that make it possible to represent
information more compactly.
  
  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.

GCC has a policy of making its code conformant to the standard ABI of
the target system. Here that means that GCC will output the DWARF EH
tables specified by the x86-64 ABI.

  [2] abi wants a single defined frozen format that can be used by 
  all vendors. 

Right, and GCC should use that.

  And
  [3] users don't want multiple copies.

Of course, that is the whole point of standardizing this information.
  
  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.

Still, that would not solve anything. If those library functions are part
of the ABI, GCC must emit a format understood by those functions. This
still means GCC cannot change the format at will. In practise, it seems
that this would not change muhch at all.
  
  A solution either needs to change the ABI or make gcc use a fixed frozen
  format.

Changing the ABI and using a library will result in a different frozen format, 
I don't see how this changes anything.

  -Geert