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
|
