Bug 1458 - mremap() fifth argument and MREMAP_FIXED not exposed in glibc
Summary: mremap() fifth argument and MREMAP_FIXED not exposed in glibc
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.3.5
: P2 normal
Target Milestone: ---
Assignee: GOTO Masanori
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-11 07:33 UTC by Michael Kerrisk
Modified: 2016-05-20 19:53 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments
Patch to fix REMAP_FIXED not defined error on MIPS and ALPHA (265 bytes, patch)
2005-10-18 07:10 UTC, Jim Gifford
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Kerrisk 2005-10-11 07:33:51 UTC
Since 2.3.31, the Linux kernel has allowed an additional 'flags' value for
mremap(): MREMAP_FIXED (defined with the value 2), which serves a similar
purpose to the mmap() MAP_FIXED flag.  If this flag is supplied, then mremap()
employs a fifth argument, 'new_address', which specifies a fixed address to
which the mapping should be relocated.  Currently, glibc does not expose the
MREMAP_FIXED definition and the mremap() prototype does not expose the fifth
argument.  Can these definitions please be exposed in glibc.
Comment 1 Ulrich Drepper 2005-10-14 13:42:57 UTC
I made the necessary changes for several architectures in the CVS trunk.
Comment 2 Jim Gifford 2005-10-18 07:10:16 UTC
Unable to compile current snapshot(1017) on MIPS and ALPHA without 
# define MREMAP_FIXED   2
added to mman.h to sysdeps/unix/sysv/linux/alpha/bits/mman.h
sysdeps/unix/sysv/linux/mips/bits/mman.h.

Will attach patch
Comment 3 Jim Gifford 2005-10-18 07:10:53 UTC
Created attachment 719 [details]
Patch to fix REMAP_FIXED not defined error on MIPS and ALPHA
Comment 4 Ulrich Drepper 2005-12-23 04:07:26 UTC
The patch is not needed anymore.
Comment 5 Arun Sharma 2007-11-17 07:22:07 UTC
Making mremap() a function with variable number of arguments changes the ABI on
x86_64. Code compiled before this change will treat %rax as scratch. After the
change, the calling conventions expect %al to be set to the number of XMM
registers passed.

Is there a reason why mremap was not versioned after the change?
Comment 6 Florian Weimer 2016-05-20 19:53:57 UTC
(In reply to Arun Sharma from comment #5)
> Making mremap() a function with variable number of arguments changes the ABI
> on
> x86_64. Code compiled before this change will treat %rax as scratch. After
> the
> change, the calling conventions expect %al to be set to the number of XMM
> registers passed.

If the called function does not use any floating point registers, this difference is immaterial.