From 5bd36fdff16871eb7d06fc26cac07e7f2703432b Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 29 Nov 2012 01:33:22 +0100 Subject: IRC. --- open_issues/vm_map_kernel_bug.mdwn | 54 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 open_issues/vm_map_kernel_bug.mdwn (limited to 'open_issues/vm_map_kernel_bug.mdwn') diff --git a/open_issues/vm_map_kernel_bug.mdwn b/open_issues/vm_map_kernel_bug.mdwn new file mode 100644 index 00000000..613c1317 --- /dev/null +++ b/open_issues/vm_map_kernel_bug.mdwn @@ -0,0 +1,54 @@ +[[!meta copyright="Copyright © 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 open_issue_gnumach]] + + +# IRC, frenode, #hurd, 2012-11-04 + + 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? + tschwinge: ETOOLOWLEVELFORME :) + tschwinge: 5bf62f2d3a8af353fac661b224fc1604d4de51ea added it + tschwinge: no, but that looks interesting + i'll have a look later + Heh, "interesting". ;-) + 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?). + braunr: Anyway, I'd already welcome a patch to simply turn that + into a more comprehensible form. + 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." + 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" + so it's an alignment constraint + the kludge disables alignment, apparently because gnumach doesn't + handle them correctly for some cases + 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?) + tschwinge: the linker i suppose + tschwinge: sorry, i don't understand what + ELF_MACHINE_USER_ADDRESS_MASK really is used for :/ + tschwinge: it looks unused for the other systems + 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 + tschwinge: 0xf8000000 means each "chunk" of linker/other blocks + are 128 MiB large + braunr: OK, thanks for looking. I guess I'll ask Roland about + it. + it could be that gnumach isn't good at aligning to large values + +[[!message-id "87fw4pb4c7.fsf@kepler.schwinge.homeip.net"]] -- cgit v1.2.3