Juan Manuel Torres Palma | 28 Jul 13:53 2015
Picon

Testing build

Hello glibc maintainers,

I have been doing some builds and tests for the last days and I would
like to know if it's possible to do some specific tests better than
the whole "make check" thing.

Reading the wiki I found out "make abi-check" but specifically I want
to know how to test conform and linknamespace tests. Is there any way
to do it?

Cheers.

--

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

Jan Engelhardt | 27 Jul 18:18 2015
Picon

dlclose blocked by static-initialized member of templated class


Given the two snippets below, I observe that dlclose behaves like a no-op
under Linux x86_64 glibc-2.19.

1. Build module.cpp into module.so, build loader.c as a program.
2. Run the loader.
3. Observed behavior:
	xxinit
	#1 dlopen 0xwhatever
	#2 dlopen 0xwhatever
	Program done
	xxexit

4. What was expected:
	xxinit
	#1 dlopen 0xwhatever
	xxexit
	xxinit
	#2 dlopen 0xwhatever
	xxexit
	Program done

I can imagine that there is a justified reason related to libdl keeping 
the reference count artificially higher, turning dlclose into a no-op, 
though what exactly is going on?

-----8<-----(module.cpp)-----
#include <cstdio>
class nothing {};
template<typename _T> struct wrap {
(Continue reading)

Dharmakan Rohit Arul Raj | 22 Jul 12:25 2015

PowerPC e6500 optimized memcmp function - Query

Hello All,

I have added an optimized PowerPC e6500 library (memcmp) to glibc v2.20 sources and I need some
clarification regarding multi-arch support.
The patch works if configured with --disable-multi-arch. But for default build, since multi-arch
support is enabled by default, I get this
error.

eglibc/opt/freescale/XLMe6500-test/obj_glibc_1_scratch/libc_pic.a(memcmp-ppc64.os):(.opd+0x0):
multiple definition of `__GI_memcmp'
eglibc/opt/freescale/XLMe6500-test/obj_glibc_1_scratch/libc_pic.a(memcmp.os):(.opd+0x0):
first defined here

As of now, we don't have any intention to add multi-arch support, so wanted to know the criteria to submit
this patch to FSF. 
Can I add this flag [--disable-multi-arch] by default for our target or should I try to resolve these
multiple definition errors?

Please let me know your comments.

Regards,
Rohit

Mihail Stefanov | 21 Jul 19:55 2015

64 bit version of sunrpc

Hi,
I am wandering how roc is ported to 64 bits. Example sizeof rpc_msg.rm_xid for 64 bit Fedora  returns 8 bytes,
when in Mac OS X 10.10 is 4 bytes. Why is the difference? Why apple decided to change all longs to int
depending of the architecture (using _L64_), when in glibc code such thing goes not exist?

Regards
Mihail
Sandhya Kumar | 15 Jul 14:43 2015
Picon

On wrapping open without ld --wrap

Hi,

I wish to customize and wrap the libc wrapper for open() system call.
At the moment, I am just trying to add a simple print statement before
the sys_open() is actually invoked.
I am very much aware of GNU linker --wrap option and in fact that
actually solves my problem. But I am altering some other functionality
in libc for which I am anyway picking my custom libc code. So I wish
to place the wrapping logic of open as well in source codes rather
than depending on linker. But when I see the eglibc v2.19 source
codes, many of the wrapper boils down to a template defined in
syscall-template.S due to which I am unable to wrap/alter the logic in
the libc function.

sysdeps/unix/sysv/linux/wordsize-64/open64.c  [EMPTY FILE]
sysdeps/unix/syscall-template.S

Can you point me on how to alter this and add a simple puts("Hello")
whenever a open() call is made? BTW I was successful in wrapping
xstat64.c and cases where the files themselves are not empty.

Adam Nielsen | 12 Jul 08:34 2015
Picon

strftime segfault vs return error code

Hi all,

I'm debugging a long standing problem with the GKrellM app, and I have
found that it is triggered by a bug that passes out-of-range data to
the strftime() function.

This results in a segfault (in strlen(), which must be called
internally by strftime) so I am wondering whether this is the ideal
behaviour.  I would have expected out-of-range values to cause strftime
to return an error (or an empty string) rather than crash.

You can reproduce this error by setting an out-of-range value for the
month, and then supplying a format specifier for the month name.  Here
is an example:

  #include <time.h>
  #include <stdio.h>
  #include <stdlib.h>
  #include <string.h>

  int main(int argc, char *argv[]) {
    char outstr[200];
    struct tm tmp;
    memset(&tmp, 0, sizeof(tmp));
    tmp.tm_mon = 1000;

    if (strftime(outstr, sizeof(outstr), "%b", &tmp) == 0) {
      fprintf(stderr, "strftime returned 0");
      exit(EXIT_FAILURE);
    }
(Continue reading)

Marc-André Lureau | 7 Jul 17:39 2015
Picon

Stream buffering and flushing behaviour

Hi

I am wondering how best to solve the following:

#include <stdio.h>
#include <assert.h>

void main()
{
    FILE *f;
    char foo[4096];
    int n;

    f = fopen("/tmp/test", "a+"); /* qemu does fdopen */
    assert(f);
    fwrite("Hello World!\n", 1, 13, f);

    n = fread(foo, 1, READ_SIZE, f);
    fprintf(stderr, "eof?%d %d", feof(f), n);

    fseek(f, 0, SEEK_SET);
    n = fread(foo, 1, sizeof(foo), f);
    fprintf(stderr, "eof?%d %d", feof(f), n);
}

with READ_SIZE >= 4096, there is no implicit flush taking place, while
with READ_SIZE < 4096 (13 for ex), it does flush to disk and
subsequent read after seek will return the expected buffer.

According to glibc manual
(Continue reading)

Stephan Bergmann | 6 Jul 14:22 2015
Picon

__memcpy_sse2_unaligned on non-8-byte aligned pointer

<https://bugzilla.redhat.com/attachment.cgi?id=1048694> is a SIGSEGV 
backtrace where apparently glibc's __memcpy_sse2_unaligned 
(sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S) is trying to write to 
an address that is not 8-byte aligned,

> Dump of assembler code for function __memcpy_sse2_unaligned:
>    0x00007fcf46f35b90 <+0>:	mov    %rsi,%rax
>    0x00007fcf46f35b93 <+3>:	lea    (%rdx,%rdx,1),%rcx
>    0x00007fcf46f35b97 <+7>:	sub    %rdi,%rax
>    0x00007fcf46f35b9a <+10>:	sub    %rdx,%rax
>    0x00007fcf46f35b9d <+13>:	cmp    %rcx,%rax
>    0x00007fcf46f35ba0 <+16>:	jb     0x7fcf46f35cad <__memcpy_sse2_unaligned+285>
>    0x00007fcf46f35ba6 <+22>:	cmp    $0x10,%rdx
>    0x00007fcf46f35baa <+26>:	jbe    0x7fcf46f35d3b <__memcpy_sse2_unaligned+427>
>    0x00007fcf46f35bb0 <+32>:	movdqu (%rsi),%xmm8
>    0x00007fcf46f35bb5 <+37>:	cmp    $0x20,%rdx
> => 0x00007fcf46f35bb9 <+41>:	movdqu %xmm8,(%rdi)
[...]

where rdi is 0x7ffc3830b63c (while rsi is 8-byte aligned at 0x7fcf4a314a08).

The code leading up to that memcpy call looks rather unsuspecting, and 
it's unclear to me from the crash report data why it caused a SIGSEGV.

However, the Intel documentation for MOVDQU states:  "If alignment 
checking is enabled (CR0.AM = 1, RFLAGS.AC = 1, and CPL = 3), an 
alignment-check exception (#AC) may or may not be generated (depending 
on processor implementation) when the operand is not aligned on an 
8-byte boundary."

(Continue reading)

Craig Ringer | 3 Jul 09:16 2015

Identifying when collations change

Hi all

The PostgreSQL database relies on the collation support of the
underlying platform, which in GNU/Linux is glibc. This works very well
for most purposes, but a problem arises when the collation rules are
updated by the platform due to bug fixes or changes in accepted
language rules.

PostgreSQL builds persistent on-disk b-tree indexes by executing the
system C library collation functions - strcoll or strcoll_l. Correct
searching of these indexes requires that the C library collation
function behaviour be pure and immutable, i.e. that any two calls over
any time period will return the same result for any given input.
Collation updates break that assumption, and indexes must be rebuilt
(REINDEXed) to ensure correct queries.

If PostgreSQL had a way to detect when the collation definition an
index was built with differed from the current collation definition it
would be very helpful, as we could then alert users to the situation,
or even repair the index if we could tell *what* changed, not just
that something changed.

This isn't only an issue with collation updates on one machine. It
also applies when a database is binary-replicated to another host with
a different glibc version. Queries on the replica may produce
incorrect results if the collations differ, and currently we have no
way to detect this situation.

The alternative to detecting and reporting issues with platform
collation changes is dropping the use of operating system collation
(Continue reading)

Sundar Dev | 26 Jun 20:26 2015
Picon

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/libc.so.6
#1  0x759abbf4 in poll () from /lib/libc.so.6
#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
Picon

[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
symbols.

Cheers.

    * 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)


Gmane