deregister_frame_info w/o register?

[Robert Lipe]

Found it.   Jason's version 1.66 of libgcc2.c is the one that did me in.

Jeffrey A Law wrote:
>   In message < 19991031164838.J19769@rjlhome.sco.com >you write:
>   > I finally got a chance to look at the horrible test results on COFF
>   > mode of i686-pc-sco3.2v5.0.5.  It looks like (even for "hello, world"
>   > in C) __deregister_frame_info() is being called when there isn't a
>   > corresponding call to register_frame_info().  Does this ring bells for
>   > anyone?
> For your target I believe they should be registered as global constructors
> and fire out of do_global_ctors.  Or something close to that -- the point is
> to grope around the startup code. 

COFF has a limit of eight characters on section names. '.eh_frame'
is longer than this.  So on OSR5 (remember, both ELF and COFF)
EH_FRAME_SECTION_ASM_OP does a weird thing to rename the section
depending upon which mode you're in.  Now, at the tail end of sco5.h we
have all this gunky code that special-cases the crtstuff builds.  For
the COFF case (i.e. !_SCO_ELF) EH_FRAME_SECTION_ASM_OP doesn't matter,
but it has to be defined.  It has to be defined or the one in defaults.h
will be picked up and will choke the assembler.  This means we have
EH_FRAME_SECTION_ASM_OP defined even though we aren't DWARF-2 and we
aren't even ELF.

So libgcc2.c comes along in __do_global_dtors() and uses an #ifdef
EH_FRAME_SECTION as the sole test of whether to deregister frame info.
Unfortunately, __do_global_ctors() uses a subtly different test as
to whether to _register_ the frame info.  So now we end up calling
deregister when we never called register.  The results aren't pretty.

It seems to me that we have too much preprocessing code in here trying
to outsmart itself.   Is there a clear direction this should take?   

RJL