Steve Ellcey | 4 Feb 00:55 2016

Running the glibc testsuite

I seem to have a memory of changes to the glibc testsuite so that it
could be run remotely.  Am I correct or am I mistaken?  I tried looking
around in the mailing lists and the wiki and such but I can't find
anything.

I normally build a cross toolchain that runs on x86 linux and generates
code for MIPS.  With the GCC testsuite I can do that and then run the
testsuite on the x86 box and use a simulator and/or remote machine to
run executables.

When I want to run the glibc testsuite though, I need to build glibc on
a MIPS box and then run 'make check' or 'make bench'.  That is more time
consuming and less convenient than the gcc testing method.  Is there a
better way to do the glibc tests with a cross-toolchain?

Steve Ellcey
sellcey@...

Waldemar Brodkorb | 25 Jan 21:53 2016

question about dlopen and $ORIGIN

Hi,

I just wondering if this test case is completey right:
https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/tst-nodelete-opened.c

Isn't it enough to open the file without using $ORIGIN.
I thought $ORIGIN is added by linking with the right commands.

Using dlopen without $ORIGIN works fine and more correct when
analyzing via strace.

What do you think?

best regards
 Waldemar

Stas Sergeev | 21 Jan 14:10 2016
Picon

swapcontext() slow

Hello.

I am implementing the user-space cooperative
threading with swapcontext(), but it is quite slow
because swapcontext() calls sigprocmask().

Firstly, I'd like to know the reason of this.
Is this so that (1) every coroutine can have its separate
signal mask, or is it to (2) allow switching in/out of a
signal handler?

I can think of the possible work-arounds, depending on an
answer to the above question.
If (1) is true, then perhaps the "light" version of
swapcontext()/setcontext() can be added that do not call
sigprocmask(). If (2) is true, then perhaps the vDSO can
be introduced to get the current signal mask. Then glibc
could compare the old and new masks and not call sigprocmask()
when not needed.

Would some optimization be possible?
It would be very good to have the user-space threads
lightweight, not calling to the kernel at all when possible.

David Niklas | 18 Dec 16:06 2015
Picon

Re: Concurrency semantics of fork

Hello,
I've been following this thread and am somewhat confused.

> > glibc supports malloc after fork in multi-threaded programs as an
> > extension, I assume.  There is quite a bit of code to support this
> > functionality.  I don't think we can remove it.  We have to fix it
> > instead.  
> 
> Correct. POSIX is the minimum we offer in many places and we should
> srive to solve real user problems and usage patterns. Particularly
> when we have already an implicit or explicit agreement to do so.

Once you fork I thought that meant that you could malloc as much as you
liked in either process since they are now separate processes with
separate memory regions.

I also consulted the man page and it guarantees thread safety too, which
makes perfect sense, since most programs will need to malloc. Note,
however, that freeing memory accessible by another thread may introduce 
a bug in the program.

vfork, on the other hand, does not permit malloc, for good reasons.

Thanks, David

David Aldrich | 18 Dec 16:01 2015
Picon

Help needed with rpath for libc

Hi

I am trying to build my application against a glibc build tree as described under 'Compile against glibc
build tree' here:

https://sourceware.org/glibc/wiki/Testing/Builds

I am having trouble with the rpath syntax. My link command fails:

$ make
g++ -o _gnuRelease/zodiac -Wl,-rpath=/data/glibc/build/glibc: /data/glibc/build/glibc/math:
/data/glibc/build/glibc/elf: /data/glibc/build/glibc/dlfcn: /data/glibc/build/glibc/nss:
/data/glibc/build/glibc/nis: /data/glibc/build/glibc/rt: /data/glibc/build/glibc/resolv:
/data/glibc/build/glibc/crypt: /data/glibc/build/glibc/nptl
-Wl,--dynamic-linker=/data/glibc/build/glibc/elf/ld.so -Wl,-whole-archive,-export-dynamic
../Kernel/_gnuRelease/libKernel.a    -Wl,--no-whole-archive -ldl
g++: error: /data/glibc/build/glibc/math:: No such file or directory
g++: error: /data/glibc/build/glibc/elf:: No such file or directory
g++: error: /data/glibc/build/glibc/dlfcn:: No such file or directory
g++: error: /data/glibc/build/glibc/nss:: No such file or directory
g++: error: /data/glibc/build/glibc/nis:: No such file or directory
g++: error: /data/glibc/build/glibc/rt:: No such file or directory
g++: error: /data/glibc/build/glibc/resolv:: No such file or directory
g++: error: /data/glibc/build/glibc/crypt:: No such file or directory
make: *** [_gnuRelease/zodiac] Error 1

I can't find an example for using rpath with multiple directories and an explanation of what the ':' is for.

Please suggest how I can fix my linker command.

(Continue reading)

Warlich, Christof | 9 Dec 08:47 2015
Picon

GLIBC API documentation sources

I cannot find any sources of the GLIBC API documentation within the glibc
Git repository: There are just a few .texi files in glibc/manual that seem to
address more general topics, but where are the API man pages, e.g. for
open() or pthread_create(), to give a few random examples? Is the GLIBC
API documentation really maintained separately from the GLIBC source code?
Why?

Vikram Singh | 8 Dec 12:52 2015
Picon

Build error in glibc using GCC-4.9.2

Hi

I am porting GCC 4.9.2 to a custom processor.
During building the glibc-2.5, we are having
following 2 errors:

"version node not found for symbol __ctype32_toupper <at> GLIBC_2.2"
"failed to set dynamic section sizes: Bad value"

We are not able to fix this issue.

Thanks in advance
-VSP

Alex Markin | 8 Dec 00:13 2015
Picon
Gravatar

undefined reference to `__stack_chk_guard' with sparc crosscompiler

Hello.

I'm trying to build a sparc cross-compiler, but I get the following error:

sparc-sun-linux-gcc   -shared -static-libgcc -Wl,-O1  -Wl,-z,defs
-Wl,-dynamic-linker=/home/alex/test/test1/cross/sparc-sun-linux/lib/ld-linux.so.2
 -B/home/alex/test/test1/glibc_objs/csu/
-Wl,--version-script=/home/alex/test/test1/glibc_objs/libresolv.map
-Wl,-soname=libresolv.so.2 -Wl,-z,combreloc -Wl,-z,relro
-Wl,--hash-style=both  -L/home/alex/test/test1/glibc_objs
-L/home/alex/test/test1/glibc_objs/math
-L/home/alex/test/test1/glibc_objs/elf
-L/home/alex/test/test1/glibc_objs/dlfcn
-L/home/alex/test/test1/glibc_objs/nss
-L/home/alex/test/test1/glibc_objs/nis
-L/home/alex/test/test1/glibc_objs/rt
-L/home/alex/test/test1/glibc_objs/resolv
-L/home/alex/test/test1/glibc_objs/crypt
-L/home/alex/test/test1/glibc_objs/mathvec
-L/home/alex/test/test1/glibc_objs/nptl
-Wl,-rpath-link=/home/alex/test/test1/glibc_objs:/home/alex/test/test1/glibc_objs/math:/home/alex/test/test1/glibc_objs/elf:/home/alex/test/test1/glibc_objs/dlfcn:/home/alex/test/test1/glibc_objs/nss:/home/alex/test/test1/glibc_objs/nis:/home/alex/test/test1/glibc_objs/rt:/home/alex/test/test1/glibc_objs/resolv:/home/alex/test/test1/glibc_objs/crypt:/home/alex/test/test1/glibc_objs/mathvec:/home/alex/test/test1/glibc_objs/nptl
-o /home/alex/test/test1/glibc_objs/resolv/libresolv.so -T
/home/alex/test/test1/glibc_objs/shlib.lds
/home/alex/test/test1/glibc_objs/csu/abi-note.o -Wl,--whole-archive
/home/alex/test/test1/glibc_objs/resolv/libresolv_pic.a
-Wl,--no-whole-archive  -Wl,--start-group
/home/alex/test/test1/glibc_objs/libc.so
/home/alex/test/test1/glibc_objs/libc_nonshared.a -Wl,--as-needed
/home/alex/test/test1/glibc_objs/elf/ld.so -Wl,--no-as-needed
-Wl,--end-group
(Continue reading)

Stefan Liebler | 2 Dec 13:09 2015
Picon

Question about iconv, UTF 8/16/32 and error reporting due to UTF-16 surrogates.

Hi,

when converting characters from UTF-16 to UTF-32 and the byte-sequence 
contains a single low-UTF-16-surrogate (0xdc00 .. 0xdfff), then iconv()
reports an error "invalid multibyte sequence".

Due to this requirement, the s390 hardware-instructions for converting 
from UTF-16 to UTF-8 / UTF-32 were disabled, because they do not report 
this error.

When converting from UTF-32 to UTF-8 / UTF-16, the s390 
hardware-instructions do not report an error, if an UTF-32 character is 
in the range of a UTF16-low-surrogate (0xdc00 .. 0xdfff).
Should iconv() report the error "invalid multibyte sequence" in such cases?
If yes, then these two hardware instructions have to be disabled, too!

As comparison, the common-code does not report an error on such a 
low-surrogates character while converting from UTF-32 to INTERNAL and 
from INTERNAL to UTF-8.

In the other direction from UTF-8 to INTERNAL, characters in the range 
of a UTF-16 surrogate are not accepted and iconv returns the error 
"invalid multibyte sequence". The same behaviour when converting from 
INTERNAL to UTF-32.

According to the comment
"/* Surrogate characters in UCS-4 input are not valid. We must catch 
this.  If we let surrogates pass through, attackers could make a 
security hole exploit by generating "irregular UTF-32" sequences.  */"
in utf-32.c, this is a security issue.
(Continue reading)

David Aldrich | 1 Dec 11:54 2015
Picon

How to 'Compile against glibc build tree' ?

Hi 

I want to build our C++ application against glibc 2.22 on Ubuntu 14.04 (which has glibc 2.19) so I am
following instructions at:

https://sourceware.org/glibc/wiki/Testing/Builds

I have cloned the glibc git repo, checked out release 2.22 and built it successfully.

Now I am following instructions:

https://sourceware.org/glibc/wiki/Testing/Builds#Compile_against_glibc_build_tree

These state:

BUILD=<path to the GLIBC build directory>

gcc \
  -Wl,-rpath=${GLIBC}:\
${GLIBC}/math:\
${GLIBC}/elf:\
${GLIBC}/dlfcn:\
${GLIBC}/nss:\
${GLIBC}/nis:\
${GLIBC}/rt:\
${GLIBC}/resolv:\
${GLIBC}/crypt:\
${GLIBC}/nptl:\
${GLIBC}/dfp \
  -Wl,--dynamic-linker=${BUILD}/lib/ld.so
(Continue reading)

Michael Eager | 29 Nov 15:20 2015

Building for older systems

I'm trying to build packages (gcc, etc.) on a newer
version of Linux which can run on an older Linux system
with an older glibc.  I've run into the memcpy versioning
problem.

Changes to memcpy in glibc-2.14 broke some programs which
used it incorrectly, so the modified memcpy was versioned
memcpy <at> GLIBC_2.14, which prevented old copies of these
buggy program from getting the new memcpy().  All well and
good.

This also means new programs compiled on a current glibc
require memcpy <at> GLIBC_2.14, even if they would work without
problem with the memcpy() from the older glibc.

I've been trying every way I can think of to build packages
with a current glibc which will run on an pre-2.14 glibc.
This includes adding a static memcpy.o to the executable.
This doesn't work, because the executable inherits the
requirements for memcpy <at> GLIBC_2.14 from libc.so.

Adding .symver statements is impractical, but also would
not work for the same reason.

Any solutions to building for an older glibc?

--

-- 
Michael Eager	 eager@...
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

(Continue reading)


Gmane