From 49a086299e047b18280457b654790ef4a2e5abfa Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Wed, 18 Feb 2015 00:58:35 +0100 Subject: Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn" This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1. --- open_issues/vm_map_kernel_bug.mdwn | 71 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 71 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..159e9d04 --- /dev/null +++ b/open_issues/vm_map_kernel_bug.mdwn @@ -0,0 +1,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 + + 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"]] + + +# IRC, frenode, #hurd, 2013-01-22 + +In context of [[libpthread]]. + + pinotree: do you understand what the fmh function does in + sysdeps/mach/hurd/dl-sysdep.c ? + ok i understand what it does + and youpi has changed the code, so he does too + youpi: do you have a suggestion about how to solve this issue in + the fmh function ? + do we remember which bug it's after? + what do you mean ? + ah + no :/ + it could be a good occasion to get rid of it, yes -- cgit v1.2.3