From 8cee055ec4fac00e59f19620ab06e2b30dccee3c Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 11 Jul 2012 22:39:59 +0200 Subject: IRC. --- open_issues/glibc/mremap.mdwn | 221 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 221 insertions(+) create mode 100644 open_issues/glibc/mremap.mdwn (limited to 'open_issues/glibc') diff --git a/open_issues/glibc/mremap.mdwn b/open_issues/glibc/mremap.mdwn new file mode 100644 index 00000000..a293eea0 --- /dev/null +++ b/open_issues/glibc/mremap.mdwn @@ -0,0 +1,221 @@ +[[!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]] + +[[!toc]] + + +# binutils gold + +## IRC, freenode, #hurd, 2011-01-12 + + I've been looking into building gold on hurd and it built fine + with one minor tweak + and it's working fine according to its test suite + the only problem is that the build system is failing to detect + the hurdish mremap which lives in libmemusage + on linux it is in the libc so the check succeeds + any hints on how to fix this properly? + hm... it's strange that it's a different library on the Hurd + are the implementations compatible? + antrik: it seems so, though the declarations differ slightly + I guess the best thing is to ask on the appropriate list(s) why + they are different... + teythoon@ganymede:~/build/gold/binutils-2.21/gold$ grep -A1 + mremap /usr/include/sys/mman.h + extern void *mremap (void *__addr, size_t __old_len, size_t + __new_len, int __flags, ...) __THROW; + vs + of course it would be possible to modify the configure script to + check for the Hurd variant too; but first we should establish whether + here is actually any reason for being different, or it's just some + historical artefact that should be fixed... + teythoon@ganymede:~/build/gold/binutils-2.21/gold$ fgrep 'extern + void *mremap' mremap.c + extern void *mremap (void *, size_t, size_t, int, ...); + the problem is that the test fails to link due to the fact that + mremap isn't in the libc on hurd + yeah, it would be possible for the configure script to check + whether it works when the hurdish extra library is added explicitely + but again, I don't see any good reason for being different here in + the first place... + so should I create a patch to move mremap? + if it's not too complicated, that would be nice... it's always + easier to discuss when you already have code :-) + OTOH, asking first might spare you some useless work if it turns + out there *is* some reason for being different after all... + so where is the right place to discuss this? + bug-hurd mailing list and/or glibc mailing list. not sure which + one is better -- I guess it doesn't hurt to crosspost... + +[[mailing_lists/libc-alpha]] is the correct list, and cross-posting to +[[mailing_lists/bug-hurd]] would be fine, too. + + antrik: some further digging revealed that mremap belongs to + /lib/libmemusage.so on both hurd and linux + the only difference is that on linux there is a weak reference + to that function in /lib/libc-2.11.2.so + $ objdump -T /lib/libc-2.11.2.so | fgrep mremap + 00000000000cf7e0 w DF .text 0000000000000028 GLIBC_2.2.5 + mremap + ah, it's probably simply a bug that we don't have this weak + reference too + IIRC we had similar bugs before + teythoon: can you provide a patch for that? + antrik: unfortunately I have no idea how that weak ref ended up + there + + teythoon: also the libmemusage.s seems to be just a debugging + library to be used by LD_PRELOAD or similar + which override those memory functions + the libc should provide actual code for those functions, even if + the symbol is declared weak (so overridable) + teythoon: are you sure that's the actual problem? can you paste + somewhere the build logs with the error? + guillem: sure + http://paste.debian.net/104437/ + that's the part of config.log that shows the detection (or the + failure to detect it) of mremap + this results in HAVE_MREMAP not being defined + as a consequence it is declared in gold.h and this declaration + conflicts with the one from sys/mman.h http://paste.debian.net/104438/ + on linux the test for mremap succeeds + teythoon: hmm oh I guess it's just what that, mremap is linux + specific so it's not available on the hurd + teythoon: I just checked glibc and seems to confirm that + CONFORMING TO This call is Linux-specific, and should not be used + in programs intended to be portable. + ah okay + so I guess we shouldn't ship an header with that declaration... + teythoon: yeah :/ good luck telling that to drepper :) + teythoon: I guess he'll suggest that everyone else needs to get + our own copy of sys/mman.h + s/our/their/ + hm, so how should I proceed? + what's your goal ? + detecting mremap ? + making binutils/gold compile ootb on hurd + I picked it from the open issues page ;) + well, if there is no mremap, you need a replacement + gold has a replacement + ok + so your problem is fixing the detection of mremap right ? + yes + ok, that's a build system question then :/ + you need to ask an autotools guy + well, actually the build system correctly detects the absence of + mremap + (gold does use the autotools right ?) + yes + oh, i'm lost now (i admit i didn't read the whole issue :/) + it is just that the declaration in sys/mman.h conflicts with + their own declaration + ah + so in the absence of mremap, they use their own builtin function + yes + and according to the test suite it is working perfectly + gold that is + the declaration in mman.h has an extra __THROW + a workaround would be to rename gold's mremap to something else, + gold_mremap for example + that's really the kind of annoying issue + you either have to change glibc, or gold + yeah + you'll face difficulty changing glibc, as guillem told you + the correct solution though IMO is to fix glibc + but this may be true for gold too + guillem: i agree + maybe it would be easiest actually to implement mremap()?... + but as this is something quite linux specific, it makes sense to + use another internal name, and wrap that to the linux mremap if it's + detected + antrik: i'm nto sure + braunr: I don't think using such workarounds is a good + idea. clearly there would be no issue if the header file wouldn't be + incorrect on Hurd + antrik: that's why i said i agree with guillem when he says "the + correct solution though IMO is to fix glibc" + what exactly is the problem with getting a patch into glibc? + the people involved + teythoon: and touching a generic header file + but feel free to try, you could be lucky + but glibc is not an linux specific piece of software, right? + teythoon: no, it's not + erm... + teythoon: but in practice, it is + supposedly not :) + braunr: BTW, by "easiest" I don't mean coding alone, but + coding+pushing upstream :-) + so the problem is, misc/sys/mman.h should be a generic header and + as such not include linux specific parts, which are not present on hurd, + kfreebsd, etc etc + antrik: yes, that's why guillem and i suggested the workaround + thing in gold + that also requires pushing upstream. and quite frankly, if I were + the gold maintainer, I wouldn't accept it. + but the easiest (and wrong) solution in glibc to avoid maintainer + conflict will probably be copying that file under hurd's glibc tree and + install that instead + antrik: implementing mremap could be relatively easy to do + actually + antrik: IIRC, vm_map() supports overlapping + well, actually the easiest solution would be to create a patch + that never goes upstream but is included in Debian, like many + others... but that's obviously not a good long-term plan + braunr: yes, I think so too + braunr: haven't checked, but I have a vague recollection that the + fundamentals are pretty much there + teythoon: so, apart from an ugly workaround in gold, there are + essentially three options: 1. implement mremap; 2. make parts of mman.h + conditional; 3. use our own copy of mman.h + 1. would be ideal, but might be non-trivial; 2. would might be + tricky to get right, and even more tricky to get upstream; 3. would be + simple, but a maintenance burden in the long term + looking at golds replacement code (mmap & memcpy) 1 sounds like + the best option performance wise + +[[!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 + + OK, how the heck do you get an undefined reference to mremap? + simply because we don't have it + mremap exists only on linux + It's in sys/mman.h + on linux? + No, on GNU/Hurd + /usr/include/i386-gnu/sys/mman.h + that's just the common file with linux + containing just the prototype + that doesn't mean there's an implementation behind + youpi: hm no, linux has an own version + uh + Ah, aye, I didn't look at the implementation.. :( + it's then odd that it was added to the generic sys/mman.h :) + Just another stub? + ah, only few linux archs have own versions + for the macro values I guess + http://paste.debian.net/175173/ on glibc/master + Hmm, so where is MREMAP_MAYMOVE coming in from? + rgrep on a linux box ;) + + but that's again linuxish + 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. + ah + we could try to remove it indeed + Should I change the code to #ifdef MREMAP_MAYMOVE & !defined + __GNU__? + no, I said we could remove the definition of MREMAP_MAYMOVE itself -- cgit v1.2.3