David Livshin | 29 Jul 06:40 2014

Thread safety of functions generated when using -ffinite-math-only gcc command option


gcc ( when called with -ffinite-math-only option ) generates calls to 
"__<name>_finite" functions ( e.g. __exp_finite ) - which of these 
functions are thread safe?
May it be assumed that  "__<name>_finite" function is thread safe iff 
"<name>" is thread safe?

Thank you in advance,

David Livshin

Joël Krähemann | 26 Jul 17:13 2014

parenthesis while addressing struct member

I experienced problems as not using parenthesis with addressing 
operator. Does someone know what's correct?


             int e = INTERNAL_SYSCALL (futex, __err, 4, 
         __lll_private_flag (FUTEX_LOCK_PI,
private), 1, 0);


              pthread_mutex_init(&(thread->timelock_mutex), NULL);

Shaun Jackman | 24 Jul 20:54 2014

Building glibc 2.19 for OS/ABI UNIX - System V

I’m building glibc 2.19 on CentOS 5.10. It built, and that makes me
happy. It unfortunately doesn’t load with the system’s default loader
/lib64/ld-2.5.so because the ABI UNIX - Linux is incompatible. How can
I build glibc 2.19 that has an OS/ABI of UNIX - System V rather than
UNIX - Linux?


$ LD_LIBRARY_PATH=~/local/Cellar/glibc/2.19/lib ~/local/bin/hello
/home/sjackman/local/bin/hello: error while loading shared libraries:
/home/sjackman/local/Cellar/glibc/2.19/lib/libc.so.6: ELF file OS ABI
$ readelf -h ~/local/Cellar/glibc/2.19/lib/libc-2.19.so |grep ABI
  OS/ABI:                            UNIX - Linux
  ABI Version:                       0

glibc 2.19
Linux headers 3.15.6
binutils 2.24
gcc 4.4.7
CentOS 5.10


Linda A. Walsh | 19 Jul 04:57 2014

how to redirect glibc's dump output ?

How can I redirect glibc's dump output to a file -- it seems to ignore 
of stdout and stderr.

Barring that, how can I disable the output -- i.e. just let it leave the 


Chip Bagwell | 7 Jul 18:33 2014

Does pthread_mutex_lock/unlock require and imply a memory barrier for all addressable memory?

Dear glibc-help community,

In reading the POSIX 2008 standards found here,


the following paragraph is written regarding memory synchronization.

"Applications shall ensure that access to any memory location by more
than one thread of control (threads or processes) is restricted such
that no thread of control can read or modify a memory location while
another thread of control may be modifying it. Such access is
restricted using functions that synchronize thread execution and also
synchronize memory with respect to other threads. The following
functions synchronize memory with respect to other threads:"

I read the "synchronize memory with respect to other threads" to mean
that a memory barrier is required in both pthread_mutex_lock() and
pthread_mutex_unlock() along with the other mentioned functions in the
standard.  Otherwise what would be protecting the data
structures/variables you are trying to access/modify inside the
critical section protected by the mutex?

Am I missing something that is leading me to the wrong interpretation
of the POSIX standard?

Thanks in advance!--

Chip Bagwell
(Continue reading)

Warlich, Christof | 4 Jul 09:15 2014

-magign-double on i686

Dear glibc community,

for various reasons being out of my control, I have to compile an application with -malign-double for a i686
(i.e. 32 bit) Linux system. With glibc being the only library used by that application, I wonder which
pitfalls I may run into?

I roughly skimmed the data types of the glibc API, and with very few exceptions (I actually just found one),
glibc's API doesn't seem to use structures that have different internal padding when using either 32 bit
or 64 bit alignment. Thus, is it right that I'm on the save side as long as my application does not use any
glibc functions (or macros) expecting (or returning) structures containing long long or double?

To push the topic even further, the only example I found that seems to have different padding when using
either 32 bit or 64 bit alignment is struct aiocb64, due to its member __off64_t aio_offset:

struct aiocb64
  int aio_fildes;		/* File desriptor.  */
  int aio_lio_opcode;		/* Operation to be performed.  */
  int aio_reqprio;		/* Request priority offset.  */
  volatile void *aio_buf;	/* Location of buffer.  */
  size_t aio_nbytes;		/* Length of transfer.  */
  struct sigevent aio_sigevent;	/* Signal number and value.  */

  /* Internal members.  */
  struct aiocb *__next_prio;
  int __abs_prio;
  int __policy;
  int __error_code;
  __ssize_t __return_value;

(Continue reading)

Joël Krähemann | 2 Jul 13:05 2014


Hi, my name is Joël Krähemann and I'm developing Advanced Gtk+
Sequencer. I get the following backtrace out of gdb. `ags` should be
thread safe so perhaps it's more related to glib and the root cause
may be line 4 and: have_lock=0

I'll read the source code of glib for further investigation, assumed
someone knows the problem it would be nice to know it.

What about ignoring SIGABRT?

            7fff937d0000-7fff93fd0000 rw-p 00000000 00:00 0
            7fff93fd0000-7fff93fd1000 ---p 00000000 00:00 0
            7fff93fd1000-7fff947d1000 rw-p 00000000 00:00 0
            7fff947d1000-7fff947d2000 ---p 00000000 00:00 0
            7fff947d2000-7fff94fd2000 rw-p 00000000 00:00 0
            7fff94fd2000-7fff94fd3000 ---p 00000000 00:00 0
            7fff94fd3000-7fff957d3000 rw-p 00000000 00:00 0
            7fff957d3000-7fff957d4000 ---p 00000000 00:00 0
            7fff957d4000-7fff95fd4000 rw-p 00000000 00:00 0
            7fff95fd4000-7fff95fd5000 ---p 00000000 00:00 0
            7fff95fd5000-7fff967d5000 rw-p 00000000 00:00 0
            Program received signal SIGABRT, Aborted.
            [Switching to Thread 0x7fffeec86700 (LWP 15013)]
            0x00007ffff0303349 in __GI_raise (sig=sig <at> entry=6) at
            56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
            (gdb) make ags
            (gdb) bt
            #0 0x00007ffff0303349 in __GI_raise (sig=sig <at> entry=6) at
(Continue reading)

Waldemar Brodkorb | 28 Jun 10:49 2014

libgcc_s.so.1 must be installed for pthread_cancel to work

Dear Libc Hackers,

I recently decided to change my toolchain to use a static libgcc.
This initially worked fine so far. So there is no libgcc_s.so.1 
in my toolchain nor on my target.

Now I recognized that for backtrace functions and pthread_cancel,
dlopen is used to get the required unwinding code from

Is there a way to avoid libgcc_s.so.1 when using GNU libc?
Is there a technical reason why the needed code can not be linked
statically from libgcc_eh.a or a libgcc.a (with contains libgcc_eh.a
functions, in the case of a gcc build with static libgcc)?

There are other C libraries, which do not use any unwinding code
from libgcc_eh.a to implement pthread_cancel.

BTW: Is static linking with GNU libc supported or discouraged?
I know there would be still the issue with NSS (but there is a FAQ
entry on your site, which explains a solution for that), but is static
linking a supported method or should I avoid it with GNU libc?

Thanks in advance for clarifying any of my misunderstandings,

best regards

Nathan Lynch | 28 Jun 00:49 2014

missing bits/syscall.h when cross-building scanf15.c test

With current master (6f12d0629f41) I get the following error when trying
to run "make check":

$ printf "CC=arm-linux-gnueabihf-gcc\nBUILD_CC=gcc\n" > configparms
$ CC=arm-linux-gnueabihf-gcc ../../../src/glibc.git/configure \
  --prefix=/usr --disable-profile --host=arm-linux-gnueabihf \
$ make
$ make test-wrapper='/srv/dev/src/glibc.git/scripts/cross-test-ssh.sh
imx6sl' check
arm-linux-gnueabihf-gcc scanf15.c -c -std=gnu99 -fgnu89-inline  -O2
-Wall -Winline -Wundef -Wwrite-strings -fmerge-all-constants
-frounding-math -g -Wstrict-prototypes   -I../libio -I../stdlib
-I../wcsmbs -I../time -I../string -I../wctype       -I../include
-I/srv/dev/build/glibc/armhf/stdio-common  -I/srv/dev/build/glibc/armhf
 -I../sysdeps/unix/sysv/linux/arm  -I../nptl/sysdeps/unix/sysv/linux
-I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread
-I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../nptl/sysdeps/unix/sysv
-I../sysdeps/unix/sysv  -I../sysdeps/unix/arm  -I../nptl/sysdeps/unix
-I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/arm/armv7/multiarch
 -I../sysdeps/arm/armv7  -I../sysdeps/arm/armv6t2
-I../sysdeps/arm/armv6  -I../sysdeps/arm/nptl  -I../sysdeps/arm/include
-I../sysdeps/arm  -I../sysdeps/arm/soft-fp  -I../sysdeps/wordsize-32
-I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754/dbl-64
-I../sysdeps/ieee754  -I../sysdeps/generic  -I../nptl  -I.. -I../libio
-I. -nostdinc -isystem
(Continue reading)

Linlin Yan (颜林林 | 5 Jun 17:29 2014

Re: Asking for Help on Seeking to End of File

Hi Godmar,

Thank you for your suggestion!

Actually, what the issue affects on our server is a python2-based
application that is using buffered file I/O functions. In addition, I
guess there are many other (scientific computing, biological in our
case) programs also have such problem potentially, since many
non-computer-science background developers usually use those
fopen/fseek/fread functions. So, I would like to know what parameters
of file system and/or storage device could affect the buffered I/O
behaviour, and I think such tuning on system level could help to solve
the problem easier.

On Thu, Jun 5, 2014 at 10:17 PM, Godmar Back <godmar@...> wrote:
> The obvious suggestion would be to not use stdio. What's the benefit of
> using it with such large files?
> Alternatively, you could try setbuf(f, NULL) to turn buffering off - if all
> you're doing is large fread/fwrite, that perhaps shouldn't make a
> difference.
>  - Godmar
> On Thu, Jun 5, 2014 at 7:17 AM, Linlin Yan (颜林林) <yanll@...>
> wrote:
>> Dear developers,
(Continue reading)

Linlin Yan (颜林林 | 5 Jun 13:17 2014

Asking for Help on Seeking to End of File

Dear developers,

I recently noticed that glibc does not move file cursor to the exact
position when fseek(fp, 0, SEEK_END), instead it move to another
position before it and read the bytes left.

Here goes a simple reproducible example (tested in glibc-2.17):

$ cat foo.c
#include <stdio.h>
int main(int argc, char * const *argv)
   FILE *fp = fopen(argv[1], "rb");
   fseek(fp, 0, SEEK_END);
   return 0;
$ gcc foo.c
$ strace ./a.out ~/Research/Data/GRCh38.fa  # This is a big file for
testing (3GB)
open("/home/yanll/Research/Data/GRCh38.fa", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3255188431, ...}) = 0
0) = 0x7fbcc4f70000
fstat(3, {st_mode=S_IFREG|0644, st_size=3255188431, ...}) = 0
lseek(3, 3255185408, SEEK_SET)          = 3255185408
close(3)                                = 0
munmap(0x7fbcc4f70000, 4096)            = 0
(Continue reading)