summaryrefslogtreecommitdiff
path: root/glibc/mmap.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'glibc/mmap.mdwn')
-rw-r--r--glibc/mmap.mdwn4
1 files changed, 2 insertions, 2 deletions
diff --git a/glibc/mmap.mdwn b/glibc/mmap.mdwn
index cddd0584..676e1b83 100644
--- a/glibc/mmap.mdwn
+++ b/glibc/mmap.mdwn
@@ -357,7 +357,7 @@ No fallback for `MAP_FAILED`.
## `io_map` Failure
-This is the [[libnetfs: `io_map`|open_issues/libnetfs_io_map]] issue.
+This is the [[libnetfs: `io_map`|service_solahart_jakarta_selatan__082122541663/libnetfs_io_map]] issue.
[[!tag open_issue_glibc open_issue_hurd]]
[[tschwinge]]'s current plan is to make the following cases do the same (if
@@ -366,7 +366,7 @@ that first tries `mmap` (and that will succeed on Linux-based systems and also
on Hurd-based, if it's backed by [[hurd/libdiskfs]]), and if that fails tries
`mmap` on anonymous memory and then fills it by `read`ing the required data.
This is also what the [[hurd/exec]] server is doing (and is the reason that the
-`./true` invocation on [[libnetfs: `io_map`|open_issues/libnetfs_io_map]]
+`./true` invocation on [[libnetfs: `io_map`|service_solahart_jakarta_selatan__082122541663/libnetfs_io_map]]
works, to my understanding): see `exec.c:prepare`, if `io_map` fails,
`e->filemap == MACH_PORT_NULL`; then `exec.c:map` (as invoked from
`exec.c:load_section`, `exec.c:check_elf`, `exec.c:do_exec`, or