Re[3]: [Gc] boehm-gc breakage between binutils 2.16.1 and 2.17 on FreeBSD[7.2]

Ivan Maidanski ivmai at mail.ru
Tue Sep 1 11:10:17 PDT 2009


Hi!

Loren James Rittle <rittle at latour.labs.mot.com> wrote:
>
> > I don't like the check "__FreeBSD__ >= 7" because it means I should
> > have to copies of libgc (pre-v7 and v7+) and choose which one to use
> > at runtime if I'd like to write an app running on both FreeBSD
> > versions. Could the libgc itself choose the proper registration
> > strategy at runtime (depending on FreeBSD release)?
> 
> Ivan,
> 
> First of all, I agree with you on one major point, I don't like the
> check "__FreeBSD__ >= 7" either.  IMHO, it would have been better (by
> some metrics) if HAVE_DL_ITERATE_PHDR was enabled by a configure-time
> check.  However, (1) I know that gc maintainers don't use them (for
> other good reasons: stability of a port configuration in fragile
> code?) and (2) this check is no worse than the existing "is linux? is
> glibc version X? is glibc actually configured to support dl?" which I
> adapted for the point of inflection on the FreeBSD system (which is
> exactly and concisely defined by "__FreeBSD__ >= 7" according to my
> CVS research; no version of FreeBSD6 has it, all versions of FreeBSD7 do).

"is linux?" is out of this kind (I hardly imagine a same native executable file which could be launched both on linux and non-linux OSes). 

> 
> Given the way every other port of gc works, it would take extra code
> to make this work the way you ponder.  An additional complication: How
> would one produce a proper pre-FreeBSD 7 binary, that also knows about
> this post-FreeBSD 7 feature, without using the compiler and headers
> from a FreeBSD 7 system?  Like most unix, FreeBSD attempts to provide
> backwards compatibility in the forward releases but (on FreeBSD, at
> least AFAIK) you typically need to compile on the oldest (major)
> version that you want to support.  Unless we taught the gc code itself
> how to completely define the API of dl_iterate_phdr and the related
> required stuctures used in the callback, there really is no way to
> compile the code on a system that does not have it.  Once you compile
> the code with (e.g.) the FreeBSD 7 compiler and its headers, then it
> will only run from that point forward.  This may be different than how
> glibc attempts to work.
> 
> Finally, we could make the symbol weak as glibc does, but it would buy
> you absolutely nothing in the FreeBSD case since the produced binary
> is already bound to FreeBSD7.  If anyone knows a practical way around
> this issue, then I will gladly defer [but having been a gcc/FreeBSD
> maintainer through ~4 major releases of FreeBSD and 2 major releases
> of FSF gcc, I know these practical issues fairly well; it is also why
> I studied and tested the proposed patch against so many different
> compiler and binutils configurations].

Ok. Great thanks for explaining it. (I haven't much knowledge of FreeBSD internals.)

> 
> Regards,
> Loren

PS. What a pretty platform is Win32 ;) - you can build GC on any Win32 host (using the proper compiler, say, MinGW or older VC++) targeting, say, i80386 and it will work on any of Win95+/NT/2000+ on any i386 (including PARALLEL_MARK support if multicore available). More over, Win32 is nearly the only platform that for which incremental collection is implemented nearly out-of-the-box (even more, offering 2 different implementations).

Bye.


More information about the Gc mailing list