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/binutils_gold.mdwn | 181 ++--------------------------------------- 1 file changed, 5 insertions(+), 176 deletions(-) (limited to 'open_issues/binutils_gold.mdwn') diff --git a/open_issues/binutils_gold.mdwn b/open_issues/binutils_gold.mdwn index aa6843a3..9eeebf2d 100644 --- a/open_issues/binutils_gold.mdwn +++ b/open_issues/binutils_gold.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 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 @@ -8,180 +9,8 @@ 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]] +[[!tag open_issue_binutils open_issue_porting]] -Have a look at GOLD / port as needed. +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. +Apparently it needs [[glibc/mremap]]. -- cgit v1.2.3