[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] glibc 64-bit obstack support

From: Alan Modra
Subject: Re: [PATCH] glibc 64-bit obstack support
Date: Tue, 29 Jul 2014 10:25:58 +0930
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Jul 28, 2014 at 12:36:21PM -0700, Roland McGrath wrote:
> This is definitely not going to make it into glibc-2.20, so you might want
> to wait until we're out of release freeze to worry too much about the
> glibc-oriented bits.

That's fine.  I figured the patch wasn't 2.20 material.  I copied the
series to libc-alpha because patch 4/5 touches rather a lot of glibc
specific support, and I'd already posted a previous attempt to
libc-alpha to explore the possibility of switching to using size_t

>  Meanwhile, you can iron out your other cleanups with
> gnulib folks.
> For glibc you need to do some more work to make the provision of
> compatibility symbols clean.  The entire compatibility build needs
> to be protected with a SHLIB_COMPAT test.  The compatibility symbols
> need to be made unavailable at link time, using versioned_symbol macros.

Yes, I realised this after posting the patch.  I'm starting to
question my sanity in attempting to fix this obstack problem properly.
It would have been so much easier to just fix the gdb bug I ran into:


Oh well.  At least I have a working knowledge of glibc internals that
makes it reasonably easy to fix the compat issue.  BTW, this obstack
problem has been known since at least 2007, and I suspect the main
reason it has remained unfixed is the number of hoops that need to be
negotiated before a patch can be committed..  It's not just gnulib
and glibc, but eg. to update the ancient obstack.h in libiberty, gcc,
gdb and gas all needed fixes to remove improper use of obstack


Alan Modra
Australia Development Lab, IBM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]