glibc:rth/execl

Last commit made on 2016-02-09
Get this branch:
git clone -b rth/execl https://git.launchpad.net/glibc

Branch merges

Branch information

Name:
rth/execl
Repository:
lp:glibc

Recent commits

5b78856... by Richard Henderson

alpha: Implement execl{,e,p} without double stack allocation

4577d84... by Richard Henderson

x32: Implement execl{,e,p} without double stack allocation

072dce8... by Richard Henderson

i386: Implement execl{,e,p} without double stack allocation

447f711... by Richard Henderson

x86_64: Implement execl{,e,p} without double stack allocation

f685eee... by Richard Henderson

Move posix/execl files to sysdeps/

This will allow them to be overridable.

c4c95c5... by Adhemerval Zanella <adhemerval dot zanella at linaro dot org>

posix: Remove dynamic memory allocation from execl{e,p}

GLIBC execl{e,p} implementation might use malloc if the total number of i
arguments exceed initial assumption size (1024). This might lead to
issue in two situations:

1. execl/execle is stated to be async-signal-safe by POSIX [1]. However
   if execl is used in a signal handler with a large argument set (that
   may call malloc internally) and the resulting call fails, it might
   lead malloc in the program in a bad state.

2. If the functions are used in a vfork/clone(VFORK) situation it also
   might issue malloc internal bad state.

This patch fixes it by using stack allocation instead. It also fixes
BZ#19534.

Tested on x86_64.

Changes from previous version:

- Remove arbitrary limit on stack allocation for argument handling
  (it is arbitrary and does no impose any limit since it does not
  consider current stack size neither stack size limit).

[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html

 [BZ #19534]
 * posix/execl.c (execl): Remove dynamic memory allocation.
 * posix/execle.c (execle): Likewise.
 * posix/execlp.c (execlp): Likewise.
Message-Id: <email address hidden>

ebf1264... by Rajalakshmi Srinivasargahvan

powerpc: Regenerate libm-test-ulps

5163b4b... by Joseph Myers <email address hidden>

Fix MIPS mmap negative offset handling for consistency (bug 19550).

The handling of negative offsets in MIPS mmap is inconsistent with
other architectures, as shown by failure of the test
posix/tst-mmap-offset for o32 and n32. The MIPS mmap syscall uses a
signed argument and does a signed arithmetic shift on it, whereas the
glibc semantics expected by that test are for the offset to be
considered as a large positive offset. This patch makes MIPS
consistent with other architectures as far as possible by using the
mmap2 syscall on o32 (#including the generic implementation), and
making mmap not an alias for mmap64 for n32, with a custom
implementation for n32 that zero-extends the offset argument to 64-bit
before calling the mmap syscall.

Tested for MIPS64 (o32, n32, n64).

 [BZ #19550]
 * sysdeps/unix/sysv/linux/mips/mips32/mmap.c: New file.
 * sysdeps/unix/sysv/linux/mips/mips64/mmap64.c: Move to ....
 * sysdeps/unix/sysv/linux/mips/mips64/n64/mmap64.c: ... here.
 * sysdeps/unix/sysv/linux/mips/mips64/n32/mmap.c: New file.
 * sysdeps/unix/sysv/linux/mips/mips64/n32/syscalls.list (mmap64):
 New syscall entry.
 * sysdeps/unix/sysv/linux/mips/mips64/n64/syscalls.list (mmap):
 New syscall entry.
 * sysdeps/unix/sysv/linux/mips/mips64/syscalls.list (mmap): Remove
 syscall entry.

0f0f4db... by Mark J. Wielaard

Revert "elf/elf.h: Add new 386 and X86_64 relocations from binutils."

This reverts commit 3da75f08818fa3d217e5d566477c7001cb774792.

glibc 2.23 hard freeze doesn't allow this change at this time.

3da75f0... by Mark J. Wielaard

elf/elf.h: Add new 386 and X86_64 relocations from binutils.

The following new 386 and X86_64 were added to binutils. They are
non-dynamic relocations, so don't need direct handling in glibc.
But other programs, like elfutils, use the glibc elf.h definitions
for the names and numbers when inspecting ET_REL files.

R_386_GOT32X was proposed in
https://groups.google.com/forum/#!topic/ia32-abi/GbJJskkid4I

X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX were proposed in
https://groups.google.com/forum/#!topic/x86-64-abi/n9AWHogmVY0

There also used to be R_X86_64_PC32_BND and R_X86_64_PLT32_BND
but those already got deprecated in
https://groups.google.com/d/msg/x86-64-abi/-hdQyMixt8Y/XFDOvioG85cJ

 * elf/elf.h (R_386_GOT32X): New.
 (R_386_NUM): Update.
 (R_X86_64_GOTPCRELX: New.
 (R_X86_64_REX_GOTPCRELX): New.
 (R_X86_64_NUM): Update.