[[!meta copyright="Copyright © 2010, 2011 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_binutils]] Have a look at GOLD / port as needed. # teythoon's try / `mremap` issue IRC, #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.