1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
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
<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...
[[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
<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
locating it. [[Talk to me|tschwinge]] if you'd like to have a look at this.
# IRC, OFTC, #debian-hurd, 2012-06-19
<bdefreese> OK, how the heck do you get an undefined reference to mremap?
<youpi> simply because we don't have it
<pinotree> mremap exists only on linux
<bdefreese> It's in sys/mman.h
<pinotree> on linux?
<bdefreese> No, on GNU/Hurd
<bdefreese> /usr/include/i386-gnu/sys/mman.h
<youpi> that's just the common file with linux
<youpi> containing just the prototype
<youpi> that doesn't mean there's an implementation behind
<pinotree> youpi: hm no, linux has an own version
<youpi> uh
<bdefreese> Ah, aye, I didn't look at the implementation.. :(
<youpi> it's then odd that it was added to the generic sys/mman.h :)
<bdefreese> Just another stub?
<pinotree> ah, only few linux archs have own versions
<youpi> for the macro values I guess
<pinotree> http://paste.debian.net/175173/ on glibc/master
<bdefreese> Hmm, so where is MREMAP_MAYMOVE coming in from?
<youpi> rgrep on a linux box ;)
<youpi> <bits/mman.h>
<youpi> but that's again linuxish
<bdefreese> 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.
<youpi> ah
<youpi> we could try to remove it indeed
<bdefreese> Should I change the code to #ifdef MREMAP_MAYMOVE & !defined
__GNU__?
<youpi> no, I said we could remove the definition of MREMAP_MAYMOVE itself
|
