summaryrefslogtreecommitdiff
path: root/service_solahart_jakarta_selatan__082122541663/glibc/mremap.mdwn
blob: c17506d7d94b7b3060f48559ab8418799978c51b (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[!tag open_issue_glibc]]

The Hurd does not currently support the `mremap` function.

For the `MREMAP_MAYMOVE` case it is easy to work around; see
`[binutils]/gold/mremap.c`, for example.

Also see the discussion of [[glibc/mmap]].

[[!toc]]


# IRC, freenode, #hurd, 2011-01-12

    <antrik> maybe it would be easiest actually to implement mremap()?...
    <braunr> antrik: i'm nto sure
    <braunr> antrik: implementing mremap could be relatively easy to do
      actually
    <braunr> antrik: IIRC, vm_map() supports overlapping
    <antrik> braunr: yes, I think so too
    <antrik> braunr: haven't checked, but I have a vague recollection that the
      fundamentals are pretty much there

[[!taglink open_issue_glibc]]: check if it is possible to implement `mremap`.
[[I|tschwinge]] remember some discussion about this, but have not yet worked on
locating it.  [[Talk to me|tschwinge]] if you'd like to have a look at this.


# IRC, OFTC, #debian-hurd, 2012-06-19

    <bdefreese> OK, how the heck do you get an undefined reference to mremap?
    <youpi> simply because we don't have it
    <pinotree> mremap exists only on linux
    <bdefreese> It's in sys/mman.h
    <pinotree> on linux?
    <bdefreese> No, on GNU/Hurd
    <bdefreese>  /usr/include/i386-gnu/sys/mman.h
    <youpi> that's just the common file with linux
    <youpi> containing just the prototype
    <youpi> that doesn't mean there's an implementation behind
    <pinotree> youpi: hm no, linux has an own version
    <youpi> uh
    <bdefreese> Ah, aye, I didn't look at the implementation.. :(
    <youpi> it's then odd that it was added to the generic sys/mman.h :)
    <bdefreese> Just another stub?
    <pinotree> ah, only few linux archs have own versions
    <youpi> for the macro values I guess
    <pinotree> http://paste.debian.net/175173/ on glibc/master
    <bdefreese> Hmm, so where is MREMAP_MAYMOVE coming in from?
    <youpi> rgrep on a linux box ;)
    <youpi> <bits/mman.h>
    <youpi> but that's again linuxish
    <bdefreese> Aye but with us having that in the header it is causing some
      code to be run which utilizes mremap.  If that wasn't defined we wouldn't
      be calling it.
    <youpi> ah
    <youpi> we could try to remove it indeed
    <bdefreese> Should I change the code to #ifdef MREMAP_MAYMOVE & !defined
      __GNU__?
    <youpi> no, I said we could remove the definition of MREMAP_MAYMOVE itself