libcc_s.so and libc.so curcular dependency on FreeBSD

[Alexander Kabaev <kabaev at gmail dot com>]

Hi,

I am working on integrating GCC 4.1.x series into FreeBSD src/ tree.
I've been running with the new compiler on FreeBSD 7.0 for quite a while
now, but was hesitant to commit my changes because of a couple of
unsolved issues. I would really appreciate your input on the way to
overcome them.

One of the main goals for the upcoming compiler refresh in FreeBSD was
to start using shared libgcc_s.so.1, something we did not do before.
Ideally I want libgcc_s.so.1 built from FreeBSD src/ tree to be 100%
binary compatible with the library build from stock GCC sources as
checked out from FSF SVN repository. This is where the first problem
lies.

libgcc_s.so.1 depends on libc.so.1 (and libpthread.so) for symbols like
malloc, free, pthread_once, pthread_mutex_lock, etc.

libc in turn depends on libgcc_s.so.1 due to the default way exception
frame info information registration is implemented in FreeBSD.  Each
shared object is expected to issue calls to __register_frame_info and
__deregister_frame_info in its startup/shutdown code in order for
exception handlers to work across shared library boundaries.

This creates a dependency cycle that I need to break. The simplest way
to go appears to follow Linux's lead and eliminate the need for shared
modules to have explicit frame into registration calls at startup and
allow exception handling code to locate necessary info with the help of
dynamic loader using dl_iterate_phdr call. I went ahead and implemented
necessary code in FreeBSD's ld-elf.so.1 and with little changes in gcc
crtstuff.c and unwind-dw2-fde-glibc.c I was able to get things working.
I did not find any breakage yet and everything seems to run smoothly so
far.

I wonder if you could confirm that this is a good resolution for the
circular dependency issue or is there a better way. Since both libc and
libgcc_s will both have symbol version support turned on on them, I
cannot import the new compiler into FreeBSD until this dilemma is
solved in one way or another.

I also noticed that on Linux glibc implements some of the libgcc
symbols, namely _Unwind_Find_FDE and __register_frame_info_bases family
of functions. I wonder why it is done and if I missed something obvious
here.

I wonder if GCC team will be willing to accept gcc part of my changes
into mainstream sources if I submit a patch. What are chances of
something like this to be committed into not only trunk, but also GCC
4.1, 4.2 and 4.3 branches? FreeBSD 7.0 wants to ship with GCC 4.1, but
newer version is likely to be imported into trunk shortly after CVS is
branched for 7.0 release.

All I had to do is to extend checks for GLIBC 2.2.4 in above mentioned
GCC files to also check for suitable __FreeBSD_version__ and they
compile just fine. I also had to add Linux-compatible definition for
struct dl_phdr_info along with dl_iterate_phdr function prototype into
FreeBSD's link.h header file.

-- 
Alexander Kabaev

Attachment: signature.asc
Description: PGP signature