Steve Ellcey | 17 Dec 19:22 2014

Minimum bison requirement for building glibc/gettext

Sometime in the last couple of days I have noticed my glibc builds 
failing with:

/usr/bin/bison --yacc --name-prefix=__gettext --output plural.c plural.y
/usr/share/bison/yacc.c:94: error: invalid pure value: pure
/usr/share/bison/yacc.c:94: the top level
plural.y:46.9-16: invalid value for %define Boolean variable `api.pure'
make[2]: *** [plural.c] Error 1
make[2]: Leaving directory `/scratch/sellcey/repos/nightly2/src/glibc/intl'
make[1]: *** [intl/subdir_lib] Error 2
make[1]: Leaving directory `/scratch/sellcey/repos/nightly2/src/glibc'
make: *** [all] Error 2
Error: Make command failed, stopping build.

I haven't changed plural.y locally, I think the recent gettext merge just
caused my git checkout to create plural.y with a later timestamp then plural.c.

I am building on ubuntu 12.04 with bison 2.5.  Do I need to use a newer
bison?  It looks like the plural.c in the source tree was created by bison
2.7.  Is the required version documented somewhere?  I didn't see anything
in the glibc Wiki about the build requirements for glibc.

I can work around this by touching plural.c or updating the bison on my
build machines but I was wondering if there was a better way to handle

Steve Ellcey

(Continue reading)

Eric Neblock | 2 Dec 15:52 2014

Disabling Consistency Checks

Hello all,
  I'm working on a program based on this (
) that will stop a child when a certain function is called.

When trying to implement a hardware break for a separate program (by
using an execv) that is dynamically linked, complains with the

  Inconsistency detected by ../elf/dl-runtime.c: 79: _dl_fixup:
Assertion `((reloc->r_info) & 0xffffffff) == 7' failed!

Now, I'm sure this has to deal with altering another program's code
section and there are obvious reasons why we don't want that to happen;
however, is there a way that I can disable this check? Or (perhaps even
better), what would be the correct way of having Program A stop Program
B when a certain line of code is executed that doesn't involve preloading.

I want to avoid preloading, because right now I want to stop whenever a
C program executes a malloc; however, tomorrow I may want to stop at a
printf so I'm trying to make things as dynamic as possible.

If there is any other information that I can provide, please let me know.


Helpful information:
uname -a:
(Continue reading)

Steve Ellcey | 2 Dec 00:23 2014

Question about multiarch (not IFUNC) builds

I have a question about building multiarch GCC toolchains and was hoping
someone could help me understand how toolchains that are currently using
multiarch setups (like debian) are being built.

In these setups libraries are put in directories like /lib64/x86_64-linux-gnu
instead of just /lib64 and I have looked through the glibc configure scripts
and fragements trying to find out where the install process might decide to
put libraries in /lib64/x86_64-linux-gnu instead of just /lib64 but I don't
see anything.

GCC has --enable-multiarch that enables the multiarch functionality and
changes the search paths for system libraries. In glibc I see
--enable-multi-arch but that seems to be about IFUNCS and completely
unrelated to multiarch library paths.  So is there any configure code in glibc
that causes libraries to be placed in 'lib64/x86_64-linux-gnu' instead of
just 'lib64' or are people just moving things after the build or do they have
configure changes that they haven't contributed back to glibc?

Steve Ellcey

Zhang Zhen | 1 Dec 05:09 2014

Alignment trap question about eglibc 2.18


I have encountered Alignment trap problem about Alignment trap on eglibc 2.18 and ARM A15 board.
And i think this problem exist in glibc 2.18 too.

The log messages:
[ 5462.945839] Alignment trap: test_aligned (11601) PC=0xb6e5096c Instr=0xe591a03c
Address=0xb6f59259 FSR 0x221
[ 5462.945853] Alignment trap: test_aligned (11601) PC=0xb6e50970 Instr=0xe5b1b040
Address=0xb6f5925d FSR 0x221
[ 5462.945868] Alignment trap: test_aligned (11601) PC=0xb6e5097c Instr=0xe5912004
Address=0xb6f59261 FSR 0x221

The testcase:

#include <unistd.h>
#include <sys/mman.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <string.h>
#include <fcntl.h>

void main(void)
        volatile unsigned int i;
        void *dist;
        int fd = -1;

        fd = open("/dev/mem", O_RDWR | O_SYNC);
(Continue reading)

Wilco Dijkstra | 28 Nov 14:06 2014

isinf oddity


I noticed there is something odd with the definition of isinf in GLIBC: it returns the sign of the
infinity in the result. This is bad as neither C99 nor C++11 define this, so any software written to
take advantage of this will silently fail when a conforming implementation is used. Checking for the
sign of an infinity is rarely needed, and it is even rarer to be performance critical. A grep
through GLIBC revealed only a few uses in the printf code - all of which could be trivially fixed.
It also means we could remove the __isinf_ns(f/l) variant and make it the default as this version is
C99/C++11 conforming and is simpler/faster as a bonus.

So the question is why was this done? Is there a really convincing reason to keep the odd behaviour,
and only for isinf (not for isnormal, isfinite, isnan)? Is there a reason to support 2 separate
implementatons of isinf (eg. keep a __isinf_sign that has the existing behaviour)? Do we know
whether this "feature" is used anywhere?


Marcos Dione | 24 Nov 21:34 2014

mmap'ed robust mutexes and possible undefined behaviour

        Hello everybody. First of all, I'm not subscribed to the mailing 
list, so please CC me any responses.

        We found a situation where a robust mutex cannot be recovered
from a stale lock and we're wondering if it's simply an undefined
situation or  a bug in the kernel. Attached you will find the sample
code, which is loosely based on a glibc's test case.The gist of it is as

1. we open a file.
2. we mmap it and use that mem to store a robust mutex.
3. we lock the mutex.
4. we munmap the file.
5. we close the file.

        The example does steps 1 and 2, then creates creates tw children
who will try  to do steps 3 to 5. Of course only one gets the lock while
the other waits. If the child who  has the lock does the 4th step, then
the other child never recovers the stale lock. In any  other situation
(that is, commenting/removing the code) it works fine.

    This looks suspiciously like undefined behaviour, because it's like
we're pulling  the rug from under the mutex' feet, but in the other hand
looks like a kernel bug because  it doesn't really recover from the
situation. What do you think? 


(Not so) Random fortune:
22:22 < m4rgin4l_> hendrix no tocaba la viola, violaba la toca
(Continue reading)

Eng cent | 19 Nov 20:50 2014

getopt_long takes an option as an argument of another option which requires argument

I need help in explaining one of the behavior of getopt_long, where an
option requires an argument, but unfortunately it is followed by
another option, thus that option becomes the argument, and getopt_long
does not raise error.

I want to understand if this is by standard or a bug in getopt_long
(glibc). I wrote a sample program on Redhat (Red Hat Enterprise Linux
Server release 5.8 (Tikanga)), and glic 2.0.

For the sample program,

1. To compile
   gcc -g -o getopttest getoptlong.c
2. To run
   ./getopttest -c -d -d

Then you will see the first '-d' becomes the value of "-c" in the
console output:

$ ./getopttest -c -d -d
option c with value '-d'
option d

If I NM the symbol,
$ nm geto | grep getopttest
$ U getopt_long <at>  <at> GLIBC_2.0

It shows glibc 2.0.

(Continue reading)

Stephan Bergmann | 19 Nov 12:14 2014

Type of FD_ISSET happens to be bool in C++

While SUS mandates FD_ISSET to have return type int (in C, which is all 
SUS is concerned with), the definition

> #define __FD_ISSET(d, set) \
>   ((__FDS_BITS (set)[__FD_ELT (d)] & __FD_MASK (d)) != 0)

in bits/select.h causes it to have type bool instead in C++.  Is that by 
design or by accident?

MaShimiao | 19 Nov 08:15 2014

thread safety level of fwide

Hi, everyone

fwide() is annotated as 
Preliminary: | MT-Safe | AS-Unsafe corrupt | AC-Unsafe lock 
in the glibc manual.

After reading it's source code, I think it should be marked with race:stream.
The reasoning is fwide() uses fp several times inside without holding the lock over all of them.

How do you think about that?

The fwide()'s code is as follows:
fwide (fp, mode)
     _IO_FILE *fp;
     int mode;
  int result;

  /* Normalize the value.  */
  mode = mode < 0 ? -1 : (mode == 0 ? 0 : 1); 

  if (mode == 0 || fp->_mode != 0)
    /* The caller simply wants to know about the current orientation
       or the orientation already has been determined.  */
    return fp->_mode;

  _IO_acquire_lock (fp);
  result = _IO_fwide (fp, mode);
  _IO_release_lock (fp);
(Continue reading)

Ivan Zaigralin | 17 Nov 18:01 2014

concerning headers, glibc, and kernel upgrades

Hi! I am in the process of de-blobbing Slackware, and one of my basic
tasks consists in replacing the stock kernel with Linux-libre kernel.
Not content with merely de-blobbing the kernel, I would like to explore
the option of upgrading it, but then some questions arise.

Please excuse me if my questions are confusing or ill-informed, as I
lack expertise in kernel-related issues.

My question concerns the interplay between Linux-libre, glibc, and
the so-called kernel headers used by glibc. The wiki says:

> The headers from the most recent Linux kernel should be used. The
> headers used while compiling the GNU C library and the kernel
> binary used when using the library do not need to match. The GNU
> C library runs without problems on kernels that are older than
> the kernel headers used. The other way round (compiling the GNU C
> library with old kernel headers and running on a recent kernel)
> does not necessarily work as expected. For example you can't use
> new kernel features if you used old kernel headers to compile the
> GNU C library.

> Even if you are using an older kernel on your machine, we
> recommend you compile GNU libc with the most current kernel
> headers.  That way you won't have to recompile libc if you ever
> upgrade to a newer kernel.

So let's say glibc is built against kernel headers 3.18.* and the kernel
in use is 3.10.17. So there is a version mismatch. Isn't it possible that
some interface is different, like some struct has changed size, and then
glibc calls to kernel (or some other app calls through gibc) and kaboom?
(Continue reading)

Toby Gray | 14 Nov 11:03 2014

How thread safe is dlopen?


I've come across an issue with my use of dlopen and pthreads in my code 
and glibc 2.19. Using valgrind I've tracked it down to the following issue:

==00:00:00:05.063 23870== Thread 30:
==00:00:00:05.063 23870== Invalid write of size 8
==00:00:00:05.063 23870==    at 0x04012d4c: _dl_allocate_tls_init 
==00:00:00:05.063 23870==    by 0x05043715: pthread_create <at>  <at> GLIBC_2.2.5 
==00:00:00:05.063 23870==    by 0x00400e44: thread_function (within 
==00:00:00:05.063 23870==    by 0x05043181: start_thread 
==00:00:00:05.063 23870==    by 0x05353fbc: clone (clone.S:111)
==00:00:00:05.063 23870==    Address 0x64fbad0 is 0 bytes after a block 
of size 272 alloc'd
==00:00:00:05.063 23870==    at 0x04c2cc70: calloc (in 
==00:00:00:05.063 23870==    by 0x04012e54: _dl_allocate_tls (dl-tls.c:296)
==00:00:00:05.063 23870==    by 0x05043da0: pthread_create <at>  <at> GLIBC_2.2.5 
==00:00:00:05.063 23870==    by 0x00400e44: thread_function (within 
==00:00:00:05.063 23870==    by 0x05043181: start_thread 
==00:00:00:05.063 23870==    by 0x05353fbc: clone (clone.S:111)
==00:00:00:05.063 23870==

(Continue reading)