Re: gcc 2.8.0 is broken on linux/x86 and more bug

[hjl@lucon.org (H.J. Lu)]

>   > How does register_frame/register_frame_new get called? They are
>   > called by crtbegin.o/collect2. User doesn't use them directly.
>   > Since they are under our control, we always call the right one.
> But we don't have control over any programs or libraries that were
> compiled with the old interfaces right?  Thus, it's possible to get
> code which uses both.  Thus we have to be able to handle both right?

That is ok since we keep both. My patch keeps the old interface and
gives the new interface a new name.

> 
> Or are you saying that a library called with the old version would be
> entirely self contained and thus we don't have to worry about mixing?
> 

Yes. One shared library will only call one of the old/new interfaces
which is determined at the library build time by gcc.

> 
> Please be explicit so that we can all understand the problem and work
> towards a correct solution and avoid having to go through this again.
 
My current glibc shared library, which, BTW, uses the old interface
in its private crtbegin.o. But my new binaries generated by gcc 2.8.0
use the new one. At the startup time, the .init section is called first.

1. My glibc shared library calls __register_frame (__EH_FRAME_BEGIN__);
2. My binary calls __register_frame_new (__EH_FRAME_BEGIN__, &object);

Upon exit, the .fini section is called.

1. My glibc shared library calls __deregister_frame (__EH_FRAME_BEGIN__);
2. My binary calls __deregister_frame_new (__EH_FRAME_BEGIN__);

Please keep in mind, __EH_FRAME_BEGIN__ is a static variable local
to each binary. Since we keep both interfaces, we are ok.



-- 
H.J. Lu (hjl@gnu.org)