Almost have standard crtbegin/end with vxworks/mips gcc 3.2.3

I'm trying to upgrade our use of 3.0.3 to 3.2.3 (then hopefully 3.3)

(trying to use the standard setup to get the ctor/dtor/eh setup done)


using mips-wrs-vxworks, building an ELF file, but really it ends up as a
raw binary file at run time
so there is no .init section (no loader etc, it runs from the beginning 
of .text)

1. In 3.0.3 a munch utility is used to extract global symbols _GLOBAL__I etc
(F, D)
   to get constructors, eh frames and destructors

2.  in 3.1 up these symbols are all static by default and no longer
available (without globifying them manually)
    and the GLOBAL__F stuff disappeared (so that a real problem)

3. it would be best to pull in crtbegin/crtend and use them
   however since we need to generate a .bin file from the .elf file I
can't have a .init section run first
   it has to run a whach of assembler

4.  So iris6 has a mode that makes available __do_global_ctors()
   which does everything I need, and I can just call it

5.  so I change gcc/gcc/config/mips/vxworks.h
    #undef INIT_SECTION_ASM_OP =20
    #define HAS_INIT_SECTION

   build compiler  etc and see that=20
   great crtbegin.o/crtend.o have exactly what I want=20

6. build my whole image
    now the constructors/destructors are all GLOBAL again for some reason
   and no longer end up in the .ctors section (where they were  before step
5)
   so now do_global_ctors does not find them anymore (still does the eh
stuff though)
   but it seems ld is building up the list of constructors and 
   surrounding with __CTOR_LIST__, __CTOR_END__

7. ok fine, add some code to reference these and then link
   but the link is 2 stages
   stage 1 links everything but with -r, stage 2 converts the symbols do
   a data structure and does the final link with crtbegin/end etc....

   oddity is if I don't reference __CTOR_LIST__ the stage one link does
   not build the CTOR_LIST  but stage 2 does
   which is great (except I have no reference to them

  if I do add the code so that there is an undefined in the first link 
  the list is generated in both link stages and I get a multiply defined
  error.

--------------
So options as I see it are=20
1. ideally, change some config for the compiler to get the constructors 
   static again and use
   __do_global_ctors(), this would make it sstandard and supported going
forward
   (get rid of any references to CTOR_LIST etc...)

OR
2. remove the reference to __CTOR__LIST__ from first link
   only do in second link etc..
   this mode is half good
   using do_global_ctors() to get eh  stuff
   but have to walk the ctor list with my own code (not difficult, but
   prone to error going forward
       (or disable ld from generating the CTOR_LIST if -r is specified)

OR
3. use __do_global_ctors for eh stuff
   go back to using much to grab the constructors (crappy solution)


????? Can someone explain to me how I would get #1 working
         Its all a bit of black magic to me, not sure how the options I
set caused this change to happen
         Its almost perfect, if I could get the ctors back in the .ctors
sections and have crtbegin reference those


Thanks for any feedback
Ken Faiczak
kfaiczak@xxxxxxxxxxxx