Re: 64-bit obstack support

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Wed, 16 Jul 2014, Alan Modra wrote:

> In https://sourceware.org/ml/binutils/2014-07/msg00137.html, I bumped
> OBSTACK_INTERFACE_VERSION, thinking that with an int -> size_t change
> on some function parameters we obviously have an ABI change.
> 
> However, it seems that the bump is not really necessary due to the
> following:
> 
> - the existing obstack support only works for obstacks sized up to
>   INTMAX, so we only need to be compatible if passing a size_t in the
>   positive int range.
> - on 32-bit targets supported by glibc, sizeof(int) == sizeof(size_t),
>   so for those targets the change is just substituting an unsigned
>   parameter for one that was signed.
> - on 64-bit targets supported by glibc, a size_t parameter (at least
>   for the first or second parameter) or return from a function, is
>   passed in the same register as an int.  I checked aarch64, alpha,
>   mips64, powerpc64, s390x, sh64, sparc64, tilegx, x64_64.

I don't know about OBSTACK_INTERFACE_VERSION, but for functions exported 
from shared glibc you are likely to need new symbol versions for such a 
change.

* If the upper bits of an int parameter are undefined by the ABI, 
obviously you need new symbol versions and the compat versions of the 
functions need to clear those bits before calling the new versions.

* Even if the upper bits are defined by sign-extension, and passing a 
negative value to the function meant undefined behavior, you still need 
new symbol versions so that a binary built with the new glibc, and passing 
size_t values outside the range of int, will not try to pass those 
out-of-range values to an old libc where the parameters have type int, but 
will fail immediately when run with old glibc.  (This sort of issue is why 
<fenv.h> functions got new versions when the return types changed from 
void to int, for example - you can alias the compat version to the new 
version, but do still need the new symbol version.)

* Much the same applies to return types; in that case, the compat symbol 
must ensure that old binaries always get return values within the range of 
the type they expect to be returned.

> 	PR gdb/17133

It looks like

	[BZ #14483]

may be appropriate here.

> 	(_Noreturn): Don't rely on this being defined, define ..
> 	(__attribute_noreturn__): ..and use this instead.

Various changes such as this appear to be effectively reverting parts of 
the recent sync with gnulib.  Don't do that; if there are problems with 
the portability code, work with gnulib on fixing them.  Also, don't mix 
any formatting changes to otherwise unmodified code into the substantive 
patch.  That is,

* substantive changes to use size_t here;

* any necessary changes to the portability code;

* any fixes to formatting

should each be in separate patches, and in the portability case you should 
get agreement from gnulib as that's the primary user of the portability 
code, which is not of direct concern to glibc otherwise.

-- 
Joseph S. Myers
joseph@codesourcery.com