This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: 64-bit obstack support
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Wed, 16 Jul 2014 21:40:42 +0000
- Subject: Re: 64-bit obstack support
- Authentication-results: sourceware.org; auth=none
- References: <20140716080412 dot GB8039 at bubble dot grove dot modra dot org>
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