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
71
|
[[!meta copyright="Copyright © 2012, 2013 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 open_issue_gnumach]]
# IRC, frenode, #hurd, 2012-11-04
<tschwinge> braunr, pinotree, youpi: Has either of you already figured out
what [glibc]/sysdeps/mach/hurd/dl-sysdep.c:fmh »XXX loser kludge for
vm_map kernel bug« is about?
<pinotree> tschwinge: ETOOLOWLEVELFORME :)
<pinotree> tschwinge: 5bf62f2d3a8af353fac661b224fc1604d4de51ea added it
<braunr> tschwinge: no, but that looks interesting
<braunr> i'll have a look later
<tschwinge> Heh, "interesting". ;-)
<tschwinge> It seems related to vm_map's mask
parameter/ELF_MACHINE_USER_ADDRESS_MASK, though the latter in only used
in the mmap implementation in sysdeps/mach/hurd/dl-sysdep.c (in mmap.c, 0
is passed; perhaps due to the bug?).
<tschwinge> braunr: Anyway, I'd already welcome a patch to simply turn that
into a more comprehensible form.
<braunr> tschwinge: ELF_MACHINE_USER_ADDRESS_MASK is defined as "Mask
identifying addresses reserved for the user program, where the dynamic
linker should not map anything."
<braunr> about the vm_map parameter, which is a mask, it is described by
"Bits asserted in this mask must not be asserted in the address returned"
<braunr> so it's an alignment constraint
<braunr> the kludge disables alignment, apparently because gnumach doesn't
handle them correctly for some cases
<tschwinge> braunr: But ELF_MACHINE_USER_ADDRESS_MASK is 0xf8000000, so I'd
rather assume this means to restrict to addresses lower than 0xf8000000.
(What are whigher ones reserved for?)
<braunr> tschwinge: the linker i suppose
<braunr> tschwinge: sorry, i don't understand what
ELF_MACHINE_USER_ADDRESS_MASK really is used for :/
<braunr> tschwinge: it looks unused for the other systems
<braunr> tschwinge: i guess it's just one way to partition the address
space, so that the linker knows where to load libraries and mmap can
still allocate large contiguous blocks
<braunr> tschwinge: 0xf8000000 means each "chunk" of linker/other blocks
are 128 MiB large
<tschwinge> braunr: OK, thanks for looking. I guess I'll ask Roland about
it.
<braunr> it could be that gnumach isn't good at aligning to large values
[[!message-id "87fw4pb4c7.fsf@kepler.schwinge.homeip.net"]]
# IRC, frenode, #hurd, 2013-01-22
In context of [[libpthread]].
<braunr> pinotree: do you understand what the fmh function does in
sysdeps/mach/hurd/dl-sysdep.c ?
<braunr> ok i understand what it does
<braunr> and youpi has changed the code, so he does too
<braunr> youpi: do you have a suggestion about how to solve this issue in
the fmh function ?
<youpi> do we remember which bug it's after?
<braunr> what do you mean ?
<braunr> ah
<braunr> no :/
<braunr> it could be a good occasion to get rid of it, yes
|
