summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--open_issues/binutils.mdwn50
-rw-r--r--open_issues/binutils_gold.mdwn16
-rw-r--r--open_issues/gcc.mdwn4
-rw-r--r--open_issues/glibc/mremap.mdwn163
m---------toolchain/logs12
5 files changed, 54 insertions, 191 deletions
diff --git a/open_issues/binutils.mdwn b/open_issues/binutils.mdwn
index 2bbdc245..5c309d47 100644
--- a/open_issues/binutils.mdwn
+++ b/open_issues/binutils.mdwn
@@ -39,8 +39,8 @@ git log --reverse --topo-order --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C
-->
-Last reviewed up to the [[Git mirror's 81a734055750a1de753adfd86f7ae9e1d72575e4
-(2012-12-15) sources|source_repositories/binutils]].
+Last reviewed up to the [[Git mirror's 7c102198e4a1ecee9cf175bd4ad87ee435956cae
+(2012-12-16) sources|source_repositories/binutils]].
* Globally
@@ -123,11 +123,11 @@ Last reviewed up to the [[Git mirror's 81a734055750a1de753adfd86f7ae9e1d72575e4
Here's a log of a binutils build run; this is from our [[Git
repository|source_repositories/binutils]]'s `tschwinge/Paul_Desmond` branch,
-commit 81a734055750a1de753adfd86f7ae9e1d72575e4 (2012-12-15), run on
+commit 7c102198e4a1ecee9cf175bd4ad87ee435956cae (2012-12-16), run on
kepler.SCHWINGE and coulomb.SCHWINGE.
$ export LC_ALL=C
- $ ../Paul_Desmond/configure --prefix="$PWD".install --with-sysroot=/ SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 2>&1 | tee log_build
+ $ ../Paul_Desmond/configure --prefix="$PWD".install --enable-gold --with-sysroot=/ SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 2>&1 | tee log_build
[...]
$ make 2>&1 | tee log_build_
[...]
@@ -137,8 +137,8 @@ harmonized. Debian GCC (which is used in binutils' testsuite) likes to pass
`--sysroot=/` to `ld`, so we need to configure binutils with support for
sysroots.
-This takes up around 130 MiB, and needs roughly 5 min on kepler.SCHWINGE and
-14 min on coulomb.SCHWINGE.
+This takes up around 900 MiB, and needs roughly 11 min on kepler.SCHWINGE and
+42 min on coulomb.SCHWINGE.
<!--
@@ -155,13 +155,20 @@ formats, and more emulation vectors.
$ toolchain/logs/process binutils build
+ * gold GNU/Linux vs. GNU/Hurd
+
+ -checking for glibc ifunc support... both
+ +checking for glibc ifunc support... dyn
+
+ Missing [[IFUNC]] support on GNU/Hurd.
+
# Install
$ make install 2>&1 | tee log_install
[...]
-This takes up around 70 MiB, and needs roughly 1 min on kepler.SCHWINGE and 2
+This takes up around 150 MiB, and needs roughly 1 min on kepler.SCHWINGE and 3
min on coulomb.SCHWINGE.
@@ -177,7 +184,7 @@ min on coulomb.SCHWINGE.
$ make -k check 2>&1 | tee log_test
[...]
-This needs roughly 4 min on kepler.SCHWINGE and 24 min on coulomb.SCHWINGE.
+This needs roughly 6 min on kepler.SCHWINGE and 42 min on coulomb.SCHWINGE.
## Analysis
@@ -213,7 +220,7 @@ This needs roughly 4 min on kepler.SCHWINGE and 24 min on coulomb.SCHWINGE.
WARNING: program timed out.
FAIL: gas/i386/rept
- * IFUNC execution tests
+ * ld IFUNC execution tests
Missing [[IFUNC]] support on GNU/Hurd.
@@ -221,3 +228,28 @@ This needs roughly 4 min on kepler.SCHWINGE and 24 min on coulomb.SCHWINGE.
FAIL: Common symbol override ifunc test 1a
FAIL: Common symbol override ifunc test 1b
+
+ * gold GNU/Linux vs. GNU/Hurd
+
+ -FAIL: relro_test.sh
+ +PASS: relro_test.sh
+
+ -PASS: ver_matching_test.sh
+ +FAIL: ver_matching_test.sh
+
+ -PASS: script_test_3
+ +FAIL: script_test_3
+
+ -PASS: tls_phdrs_script_test
+ +FAIL: tls_phdrs_script_test
+
+ -PASS: ifuncmain1static
+ -PASS: ifuncmain1picstatic
+ -PASS: ifuncmain2static
+ -PASS: ifuncmain2picstatic
+ -PASS: ifuncmain4static
+ -PASS: ifuncmain4picstatic
+ -PASS: ifuncmain5static
+ -PASS: ifuncmain5picstatic
+ -PASS: ifuncmain7static
+ -PASS: ifuncmain7picstatic
diff --git a/open_issues/binutils_gold.mdwn b/open_issues/binutils_gold.mdwn
deleted file mode 100644
index 9eeebf2d..00000000
--- a/open_issues/binutils_gold.mdwn
+++ /dev/null
@@ -1,16 +0,0 @@
-[[!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
-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 open_issue_porting]]
-
-Have a look at gold / port as needed.
-
-Apparently it needs [[glibc/mremap]].
diff --git a/open_issues/gcc.mdwn b/open_issues/gcc.mdwn
index f5022c16..679cb6fb 100644
--- a/open_issues/gcc.mdwn
+++ b/open_issues/gcc.mdwn
@@ -112,9 +112,7 @@ Last reviewed up to the [[Git mirror's be3860ba8df48cca3253da4f02fd2d42d856ce80
* `--enable-gnu-unique-object`
- * `--enable-lto`, `--enable-gold`
-
- [[binutils_gold]]
+ * `--enable-lto`
* `--enable-indirect-function`
diff --git a/open_issues/glibc/mremap.mdwn b/open_issues/glibc/mremap.mdwn
index a293eea0..874c7ae0 100644
--- a/open_issues/glibc/mremap.mdwn
+++ b/open_issues/glibc/mremap.mdwn
@@ -10,177 +10,24 @@ License|/fdl]]."]]"""]]
[[!tag open_issue_glibc]]
-[[!toc]]
-
+The Hurd does not currently support the `mremap` function.
-# binutils gold
+For the `MREMAP_MAYMOVE` case it is easy to work around; see
+`[binutils]/gold/mremap.c`, for example.
-## IRC, freenode, #hurd, 2011-01-12
-
- <teythoon> I've been looking into building gold on hurd and it built fine
- with one minor tweak
- <teythoon> and it's working fine according to its test suite
- <teythoon> the only problem is that the build system is failing to detect
- the hurdish mremap which lives in libmemusage
- <teythoon> on linux it is in the libc so the check succeeds
- <teythoon> any hints on how to fix this properly?
- <antrik> hm... it's strange that it's a different library on the Hurd
- <antrik> are the implementations compatible?
- <teythoon> antrik: it seems so, though the declarations differ slightly
- <antrik> I guess the best thing is to ask on the appropriate list(s) why
- they are different...
- <teythoon> teythoon@ganymede:~/build/gold/binutils-2.21/gold$ grep -A1
- mremap /usr/include/sys/mman.h
- <teythoon> extern void *mremap (void *__addr, size_t __old_len, size_t
- __new_len, int __flags, ...) __THROW;
- <teythoon> vs
- <antrik> 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> teythoon@ganymede:~/build/gold/binutils-2.21/gold$ fgrep 'extern
- void *mremap' mremap.c
- <teythoon> extern void *mremap (void *, size_t, size_t, int, ...);
- <teythoon> the problem is that the test fails to link due to the fact that
- mremap isn't in the libc on hurd
- <antrik> yeah, it would be possible for the configure script to check
- whether it works when the hurdish extra library is added explicitely
- <antrik> but again, I don't see any good reason for being different here in
- the first place...
- <teythoon> so should I create a patch to move mremap?
- <antrik> if it's not too complicated, that would be nice... it's always
- easier to discuss when you already have code :-)
- <antrik> 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?
- <antrik> bug-hurd mailing list and/or glibc mailing list. not sure which
- one is better -- I guess it doesn't hurt to crosspost...
+[[!toc]]
-[[mailing_lists/libc-alpha]] is the correct list, and cross-posting to
-[[mailing_lists/bug-hurd]] would be fine, too.
- <teythoon> antrik: some further digging revealed that mremap belongs to
- /lib/libmemusage.so on both hurd and linux
- <teythoon> the only difference is that on linux there is a weak reference
- to that function in /lib/libc-2.11.2.so
- <teythoon> $ objdump -T /lib/libc-2.11.2.so | fgrep mremap
- <teythoon> 00000000000cf7e0 w DF .text 0000000000000028 GLIBC_2.2.5
- mremap
- <antrik> ah, it's probably simply a bug that we don't have this weak
- reference too
- <antrik> IIRC we had similar bugs before
- <antrik> teythoon: can you provide a patch for that?
- <teythoon> antrik: unfortunately I have no idea how that weak ref ended up
- there
+# IRC, freenode, #hurd, 2011-01-12
- <guillem> teythoon: also the libmemusage.s seems to be just a debugging
- library to be used by LD_PRELOAD or similar
- <guillem> which override those memory functions
- <guillem> the libc should provide actual code for those functions, even if
- the symbol is declared weak (so overridable)
- <guillem> teythoon: are you sure that's the actual problem? can you paste
- somewhere the build logs with the error?
- <teythoon> guillem: sure
- <teythoon> http://paste.debian.net/104437/
- <teythoon> that's the part of config.log that shows the detection (or the
- failure to detect it) of mremap
- <teythoon> this results in HAVE_MREMAP not being defined
- <teythoon> 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/
- <teythoon> on linux the test for mremap succeeds
- <guillem> teythoon: hmm oh I guess it's just what that, mremap is linux
- specific so it's not available on the hurd
- <guillem> teythoon: I just checked glibc and seems to confirm that
- <braunr> CONFORMING TO This call is Linux-specific, and should not be used
- in programs intended to be portable.
- <teythoon> ah okay
- <teythoon> so I guess we shouldn't ship an header with that declaration...
- <guillem> teythoon: yeah :/ good luck telling that to drepper :)
- <guillem> teythoon: I guess he'll suggest that everyone else needs to get
- our own copy of sys/mman.h
- <guillem> s/our/their/
- <teythoon> hm, so how should I proceed?
- <braunr> what's your goal ?
- <braunr> detecting mremap ?
- <teythoon> making binutils/gold compile ootb on hurd
- <teythoon> I picked it from the open issues page ;)
- <braunr> well, if there is no mremap, you need a replacement
- <teythoon> gold has a replacement
- <braunr> ok
- <braunr> so your problem is fixing the detection of mremap right ?
- <teythoon> yes
- <braunr> ok, that's a build system question then :/
- <braunr> you need to ask an autotools guy
- <teythoon> well, actually the build system correctly detects the absence of
- mremap
- <braunr> (gold does use the autotools right ?)
- <teythoon> yes
- <braunr> oh, i'm lost now (i admit i didn't read the whole issue :/)
- <teythoon> it is just that the declaration in sys/mman.h conflicts with
- their own declaration
- <braunr> ah
- <braunr> so in the absence of mremap, they use their own builtin function
- <teythoon> yes
- <teythoon> and according to the test suite it is working perfectly
- <teythoon> gold that is
- <teythoon> the declaration in mman.h has an extra __THROW
- <guillem> a workaround would be to rename gold's mremap to something else,
- gold_mremap for example
- <braunr> that's really the kind of annoying issue
- <braunr> you either have to change glibc, or gold
- <guillem> yeah
- <braunr> you'll face difficulty changing glibc, as guillem told you
- <guillem> the correct solution though IMO is to fix glibc
- <braunr> but this may be true for gold too
- <braunr> guillem: i agree
<antrik> maybe it would be easiest actually to implement mremap()?...
- <braunr> 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
<braunr> antrik: i'm nto sure
- <antrik> 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
- <braunr> antrik: that's why i said i agree with guillem when he says "the
- correct solution though IMO is to fix glibc"
- <teythoon> what exactly is the problem with getting a patch into glibc?
- <braunr> the people involved
- <guillem> teythoon: and touching a generic header file
- <braunr> but feel free to try, you could be lucky
- <teythoon> but glibc is not an linux specific piece of software, right?
- <braunr> teythoon: no, it's not
- <guillem> erm...
- <braunr> teythoon: but in practice, it is
- <guillem> supposedly not :)
- <antrik> braunr: BTW, by "easiest" I don't mean coding alone, but
- coding+pushing upstream :-)
- <guillem> 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
- <braunr> antrik: yes, that's why guillem and i suggested the workaround
- thing in gold
- <antrik> that also requires pushing upstream. and quite frankly, if I were
- the gold maintainer, I wouldn't accept it.
- <guillem> 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
<braunr> antrik: implementing mremap could be relatively easy to do
actually
<braunr> antrik: IIRC, vm_map() supports overlapping
- <antrik> 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
<antrik> braunr: yes, I think so too
<antrik> braunr: haven't checked, but I have a vague recollection that the
fundamentals are pretty much there
- <antrik> 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
- <antrik> 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
- <teythoon> 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
diff --git a/toolchain/logs b/toolchain/logs
-Subproject 857158d0abdbd9c3be942dda05b33a97115cff5
+Subproject b2218016e588eed4e81eeb85b35f58bcd784da4