------- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-29 00:35 ------- Subject: Re: INIT_PRIORITY is broken
> I believe you're correct that my changes broke the handling of > prioritized constructors in the case where we use collect2. I didn't > realize that there were targets that did that before. It used to be that constructors and destructors were run from _main and atexit, respectively. However, this didn't work for dynamically loaded objects, so I reworked the 32-bit handling to use the linker +init and +fini options. While doing this, I noticed that somebody had added the infrastructure to run prioritized constructors using collect2. So, I enabled this feature. I think Solaris still doesn't have this. > In order to fix this, I think the correct change would be to have > cgraphunit.c:cgraph_build_cdtor be smarter. In particular, it should > build one function for each priority, rather than building one function > for everything. Then, collect2 will work as before. Sounds right. > I don't think this will be too hard to implement. In > cgraph_build_cdtor_fns, we need to partition/sort the static_[cd]tors by > priority, and then pass each batch off to build_cdtor separately. Do > you want to work on this, or do you want me to do it? At the moment, I'm finding it more and more difficult to keep up with GCC issues. Think to some extent that this is caused by the growth of the GCC project. I'm doing fulltime electrical and software design for a small company here in Ottawa. At the moment, I have two ARM based boards on my desk and a video board in the works. So, I don't expect to have any significant time off until Christmas. I appreciate that you are also extremely busy. There are two related constructor issues on this target. PR 33772 is a bug in collect2. We don't strip the version info from shared library file names because HP-UX uses .sl. It is done for shared libraries using the .so extension. This causes a problem when a library is upgraded to a newer minor version using libtool's versioning scheme. The problem is libtool links shared libraries against dependent shared libraries. When this is done, the HP linker creates undefined symbols in the library for global symbols in the dependent libraries. Thus, a GLOBAL constructor with version string in a dependent library gets hardcoded into the library. As a result, it's not possible to replace dependent libraries without breaking other libraries and applications ;( In looking at this, I realized it was a bad idea to put DWARF2 EH data in the data section. We need a lot of `_GLOBAL_F*' constructors. This is the main reason we have a problems with duplicate constructor symbols (PR 30151). I think these symbols potentially will cause version update problems since they contain a random portion. It's possible PR 30151 is fixed as I don't see any failures related to this in recent builds. I think the `_GLOBAL_F*' constructors need to be hidden in a manner similar to that on linux. However, we still need collect2 to handle prioritized constructors and destructors since the sort capability of HP ld are limited. I have a little patch for the collect2 problem but I'm still pondering whether to do something different to handle the F constructors. Thanks, Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33579
