Sundar Dev | 26 Jun 20:26 2015

libc with ARM unwind tables and frame pointers

Hi List Members:

First things first- we are using GNU libc-2.19 that comes packaged in
Yocto Poky 'Daisy' release for one of our projects. This is
cross-compiled for ARMv7 and we use arm-poky-linux-gnueabi-gcc (GCC)
4.8.2 toolchain.

We use the *non-debug* version of libc in our project for obvious size
and performance reasons. With the non-debug version, when a user space
thread is executing a libc function like poll(), read(), etc., and we
attach a remote gdbserver to the process and try to get backtrace, all
we see is the following 4 backtrace frames-

(gdb) bt
#0  0x759abc00 in poll () from /lib/
#1  0x759abbf4 in poll () from /lib/
#2  0x00182c70 in ?? ()
#3  0x00182c70 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

This, I can understand, is because the non-debug version is stripped
of all debug symbols and hence GDB cannot backtrace. But here is the
interesting part- we compiled libc (and all of yocto Poky toolchain
components) with ARM unwind table and ARM frame pointers for another
reason[1]. And, I know that the version of gdb that we're using
(7.6.2) has support to backtrace using ARM unwind tables and frame
pointers (see [2] and [3]). But, even then, all we get from GDB
backtrace is the above shown output. Does anybody have any comments on
why enabling ARM unwind tables and ARM frame pointers in libc still
does not give us backtrace? And is there any other way we can get
(Continue reading)

Juan Manuel Torres Palma | 25 Jun 23:44 2015

[PATCH] Clean pthread functions namespace for C11 threads

This patch creates weak aliases for all conflicting functions with
C11 threads.h functions, allowong user to redefine them. Some functions
do not need aliases as they have already been defined as versioned


    * nptl/pthreadP.h (__pthread_mutex_timedlock, __pthread_key_delete)
    (__pthread_detach, __pthread_join): Add functions prototypes.
    * nptl/pthread_detach.c (pthread_detach): Declare as weak alias.
    (__pthread_detach): Rename pthread_detach function.
    * nptl/pthread_equal.c (pthread_equal): Declare as weak alias.
    * nptl/pthread_exit.c (pthread_exit): Likewise.
    * nptl/pthread_getspecific.c (pthread_getspecific): Likewise.
    * nptl/pthread_join.c (pthread_join): Declare as weak alias.
    (__pthread_join): Rename pthread_join function.
    * nptl/pthread_key_create.c (pthread_key_create):
    Declare as weak alias.
    * nptl/pthread_key_delete.c (pthread_key_delete):
    Declare as weak alias.
    (__pthread_key_delete): Rename pthread_key_delete function.
    * nptl/pthread_mutex_destroy.c (pthread_mutex_destroy):
    Declare as weak alias.
    * nptl/pthread_mutex_init.c (pthread_mutex_init): Likewise.
    * nptl/pthread_mutex_lock.c (pthread_mutex_lock): Likewise.
    * nptl/pthread_mutex_timedlock.c (pthread_mutex_timedlock): Likewise.
    (__pthread_mutex_timedlock): Rename pthread_mutex_timedlock function.
    * nptl/pthread_mutex_trylock.c (pthread_mutex_trylock):
    Declare as weak alias.
    * nptl/pthread_mutex_unlock.c (pthread_mutex_unlock): Likewise.
(Continue reading)

Niels Möller | 22 Jun 09:22 2015

Function calls in my ifunc resolver crash due to unitialized PLT entries.


I've recently added "fat binary" support to GNU nettle, and one of the
mechanisms used are __attribute__ ((ifunc (resolver_function))). (The
code uses a belt-and-suspenders approach to be portable also to systems
lacking both ifunc and constructors).

On x86_64, the resolver functions all call a common initialization
function, fat_init, see

It calls a couple of non-static functions, like

      uint32_t cpuid_data[4];
      _nettle_cpuid (0, cpuid_data);
      if (memcmp (cpuid_data + 1, "Genu" "ntel" "ineI", 12) == 0)
	features->vendor = X86_INTEL;

Now, it's been reported that the following test program:

  #include <stdio.h>
  #include <stdlib.h>
  #include <dlfcn.h>

  int main (int argc, char *argv[])
    void *handle;

    handle = dlopen ("", RTLD_NOW);
    if (!handle)
(Continue reading)

Juan Manuel Torres Palma | 21 Jun 22:34 2015

Multiple doubts

Hello glibc folks.

I'm currently working in some patches and I have noticed they don't
look the way I expected and I have 2 quick questions.

First of all, when I post my patches, I have to manually add the
copyright disclaimer at the beginning of each file and they appear on
the patches I submit, what just make the patches larger with useless
info. I have checked out the scripts/update-copyrights script, and I
think it would make the work, but I can't really make it work. Any
tips on this?

Another one and more important issue I have seen how you guys in the
changelog files leave some pretty comments in every commit and an
explanation stating every change in every file. I was wondering if you
do that manually (I would say you don't) or which script or git
command do you use.

Thanks in advance.


Juan Manuel Torres Palma.
Computer Science Student at Universidad de Granada.

Robert Stolarz | 20 Jun 18:52 2015

I can't recompile glibc: __libc_multiple_libcs


I have a complicated issue. I'm trying to run Unreal Engine 4 on Arch Linux x86_64, and it crashes because I
have too many shared object loaded with static TLS according to
None of that is too far out of the ordinary, but the real issue is, when I try to recompile glibc to increase
DTV_SURPLUS, I get something like 

/tmp/glibc/src/glibc-build/libc_pic.a(init-first.os):(.data+0x0): multiple definition of `__libc_multiple_libcs'

My build output looks like and patch like Can anyone help me?


Florian Weimer | 16 Jun 15:22 2015

Fixing a scalability issue in OpenSSL error reporting

OpenSSL has its own implementation of thread-local variables (using a
few global locks and a hash table indexed by the address of errno), and
the error state is needed in a few places even if no error occurs which
is visible at the application level.  This turns out to be a major
scaling issue if you have more than a few hundred OpenSSL connections in
one process (I don't know if it applies to servers as well).

Unlike errno, the error state is not of fixed size, so ideally, a
deallocation function would run, releasing the state if the error
information isn't collected before the thread terminates.

The OpenSSL implementation has a function to deallocate the error state
of *another* thread, but that's obviously racy and would have to be
turned into a NOP.

I have come up with several potential approaches:

(a) Use __thread (or C++11 thread_local with a POD) and do not add a
deallocation function.  The downside is a potential memory leak, as
mentioned above.  The existing code already has this problem, though.
Advantage is good portability to older GNU toolchain versions.

(b) Use pthread_setspecific and related functions.  This should offer
even better portability, and there is a destructor function which can
deallocate memory.  The downside is that it currently requires linking
against libpthread, which is something I want OpenSSL cease to do.  A
fully portable solution with pthread_once may lack performance, and
portable atomics more or less require a C++11 compiler outside of the
GNU ecosystem.

(Continue reading)

Waldemar Brodkorb | 15 Jun 23:23 2015

glibc 2.21 cross-compile for x86_64


I am trying to cross-compile glibc 2.21 for PCengines APU (AMD
X86_64 CPU). This worked fine for glibc 2.19 with binutils 2.25 and
gcc 4.9.2.
With glibc 2.20/glibc 2.21 I get following errors:
-m64 gconv_trans.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline
-Wundef -W
write-strings -fhonour-copts -fmerge-all-constants
-fno-asynchronous-unwind-tables -fno-ident -fno-unwind-tables
-frounding-math -fwrapv -march=btver1 -pipe -Wstrict-prototypes  -
fomit-frame-pointer        -I../include
-I../sysdeps/unix/sysv/linux/x86_64  -I../sysdeps/unix/sysv/li
nux/x86  -I../sysdeps/unix/sysv/linux/wordsize-64
-I../sysdeps/x86_64/nptl  -I../sysdeps/unix/sysv/linux/include
-I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl
-I../sysdeps/pthread  -I../sysdeps/gnu  -I../sysdeps/unix/inet
-I../sysdeps/unix/sysv  -I../sysdeps/unix/x86_64  -I../sysdeps/unix
-I../sysdeps/posix  -I../sysdeps/x86_64/64
-I../sysdeps/x86_64/fpu/multiarch  -I../sysdeps/x86_64/fpu
-I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu
-I../sysdeps/x86_64/multiarch  -I../sysdeps/x86_64  -I../sysdeps/x86
-I../sysdeps/ieee754/dbl-64/wordsize-64  -I../sysdeps/ieee754/dbl-64
-I../sysdeps/ieee754/flt-32  -I../sysdeps/wordsize-64
(Continue reading)

ISHIKAWA,chiaki | 9 Jun 19:03 2015

Question: short-read while loading .so file

I think the following question I posted to libc-alpha is probably best
answered in libc-alpha.
Here it goes.

I asked the following question to binutils mailing list first
and was advised to post it to libc-alpha. I misunderstood that dynamic
loading was handled by a component of linker.
Here it goes. The behavior was observed under Debian GNU/Linux.




While testing how mozilla thunderbird handles "short read", i.e.,
a |read| system call that returns prematurely without returning all the
octets (subsequent |read|(s) will return the octets eventually),
I was surprized at the following.

(I simulated "short read" by preloading a hand-crafted |read|, using
LD_PRELOAD and this hand-crafted |read| subtracts some numbers from the
requested number of octets (60 and 1 depending on the requested # of
octets), and perform the real |read| and return the result.
I made sure that the repeated calls of |read| with decreasing # of
requested octets appropriately read the initial requested # of octets if
they are available in the file store.
(So a |read| for 256 octets end up with three reads of 196, 59, and 1
if the caller of |read| handles the "short read" appropriately.
(Continue reading)

james harvey | 30 May 23:09 2015

Which Linux distributions are the developers of glibc using?

I started with Redhat and moved to Fedora when it came out, and have
stuck with it.

Trying to upgrade my glibc to the git master has, for the first time,
exposed me to distribution-specific patches.

There can be quite a few conflicts trying to merge in the Fedora
patches for their latest release of a package, and that project's
current source tree.

I could be wrong, of course, but I assume the glibc developers are
using a distribution that allows them to just install the glibc
source, without distribution-specific patches on top to complicate
their development.  Which ones are these?  I figure Linux From Scratch
would qualify for what I'm looking for, but want to know my options.

Tom van Dijk | 27 May 12:07 2015

dlopen with RTLD_PRIVATE?


Judging from a cursory search on the internet, quite a few people
would love to have dlopen with an RTLD_PRIVATE flag, which would allow
opening a .so file that has some internal state multiple times.

for example:

This appears to be implemented eg in UnixWare:

Our my case, I'd like to load a .so that is not thread-safe for every
thread. Using only one instance protected with a mutex is not an
option, as I'm interested in a highly parallel application.

Is this something that is difficult to implement in glibc for some
reason? Or is there already some solid alternative for this problem? A
search did not find satisfactory solutions, although there is a
workaround by copying the library to uniquely named files in /tmp on
runtime and loading each copied file separately, but I'd say you'd
agree that this is a pretty dirty solution.


(Continue reading)

Adhemerval Zanella | 20 May 16:10 2015

[PATCH] Remove socket.S implementation


This patch is another of the required adjustments for the fix for bz12683
(Race conditions in pthread cancellation) and the idea is to get rid of
assembly implementation for socket function for ports which uses socketcall.

This patch removes the socket.S implementation for all ports and replace
it by a C implementation using socketcall where it is required.  For ports
that implement the syscall directly, there is no change.

The patch idea is to simplify the socket function implementation that
uses the socketcall to be based on C implemetation instead of a pseudo
assembly implementation with arch specific parts.  All the affect
architectures (i386, microblaze, mips, powerpc, and sparc) have support
for 6 argument syscalls.

I have cross-build GLIBC for afore-mentioned ports and tested on i386,
x86_64, powerpc64le, arm, and aarch64.


	* nptl/Makefile (CFLAGS-accept.c): Add -fexceptions and
	(CFLAGS-sendto.c): Likewise.
	(CFLAGS-sendmsg.c): Likewise.
	(CFLAGS-connect.c): Likewise.
	(CFLAGS-recvmsg.c): Likewise.
	(CFLAGS-recvfrom.c): Likewise.
	* sysdeps/unix/sysv/linux/socketcall.h (SOCKOP_invalid): Define.
	(SOCKETCALL): New macro: non-cancellable socketcall.
(Continue reading)