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

Boehm, Hans hans.boehm at hp.com
Tue Sep 1 12:22:38 PDT 2009


I think we're nearing a consensus that this patch is probably the best we can do.

Looking at the release history, it looks like FreeBSD 7 is about a year and a half old?  Thus hopefully most people still running something earlier are those who never update anything, and thus won't update the GC either?

Interestingly, the posted patch seems to have arrived here with some formatting problems, e.g.

+*/ #define HAVE_DL_ITERATE_PHDR #endif

but it looks OK in the gmane archives.

I have no idea how that could happen; some mailer didn't just wrap lines, it also deleted the "+" signs.

Nonetheless, it's probably better to send patches as attachments.

Hans 

 

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ivan Maidanski
> Sent: Tuesday, September 01, 2009 11:10 AM
> To: gc at napali.hpl.hp.com
> Cc: Loren James Rittle
> Subject: Re[3]: [Gc] boehm-gc breakage between binutils 
> 2.16.1 and 2.17 on FreeBSD[7.2]
> 
> 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.
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 


More information about the Gc mailing list