On 2017-07-18 4:26 PM, John David Anglin wrote:
On 2017-07-18 3:39 PM, Rolf Eike Beer wrote:
John David Anglin wrote:
On 2017-07-18 11:13 AM, Rolf Eike Beer wrote:
Am 2017-07-18 16:32, schrieb John David Anglin:
On 2017-07-17 12:33 PM, John David Anglin wrote:
I would like to know if the gentoo folks would consider fixing the
__gmon_start__ bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=19170
There is some risk in applying the patch as rebuilding a library
package may break other
packages which depend on the library. This could break critical
tools such as binutils and
gcc. In which case, some manual intervention may be needed.
However, the transition
on Debian went fairly smoothly. As a result, we no longer have the
external symbol
__gmon_start exposed and we have correct library dependencies.
The issues with _init referred to in the BZ report are fixed. It is
now PIC; and PIE applications
work on hppa thanks to Alan Modra.
Helge: we need to add PIE load address to the kernel TODO list if
it's
not already there.
Although not ideal, we could keep the __gmon_start__ patch in
Debian.
The other approach is to install the __gmon_start__ patch and let
gentoo revert it. I'm starting
to think this is best.
I don't think there will be a big problem for Gentoo to accept it, as
long as there is a working upgrade path like "build glibc with flag
-special-foo, rebuild system, remove flag and rebuild glibc again".
And of course a hint in the release notes so it will be obvious to the
packagers what they have to take care of. That flag thing is something
that Gentoo probably can add to their build scripts, something that
e.g. keeps the symbol in the lib without exporting it during linking,
so it would be resolvable first and the reference goes away on
rebuild. Or whatever ;)
I'm not sure you fully understand the issue. It doesn't involve doing
anything special in building glibc.
The issue is this code in glibc's crtn.S:
/* Note that we cannot have a weak undefined __gmon_start__, because
that would require this to be PIC, and the linker is currently not
able to generate a proper procedure descriptor for _init. Sad but
true. Anyway, HPPA is one of those horrible architectures where
making the comparison and indirect call is quite expensive (see
the
comment in sysdeps/generic/initfini.c). */
.text
.align 4
.weak __gmon_start__
.type __gmon_start__,@function
__gmon_start__:
.proc
.callinfo
.entry
bv,n %r0(%r2)
.exit
.procend
The above hunk of code results in a weak __gmon_start__ function in
every shared library.
The function needs to be removed.
As can be seen, the function does nothing. It is called once when a
shared library is loaded.
In an application link, __gmon_start__ is resolved to one of the shared
libraries used by the application.
So, this would be a problem if the application only links to glibc
(and it's
libraries), no? The problem is not rebuilding, Gentoo is actually
totally
about rebuilding your system every now and then ;) The point is: what
must be
done to have an upgrade path from the old glibc to the new one that
will not
break the system on the way.
It's not a problem for applications that only link against libc, but
for other libraries. I'm
not aware of any way to avoid some breakage other than retaining the
old behavior. The new
glibc doesn't break anything directly. The breakage occurs when
libraries are linked with
the new crt* files.
One could build up a minimal system in a chroot. When you are sure
that it works, then
these tools could be used to get past any breakage. I don't know the
gentoo build system
so I don't know how easy this would be.
The patch will not be applied until after the 2.26 branch is created so
there is plenty of time to
consider what needs to be done.
There is one addition issue to consider. Linuxthreads is now removed
and hppa uses the
generic nptl thread support. So, old linuxthread applications will no
longer work. Changes
to nptl broke 2.25 on hppa and no doubt the code that tried to handle
both methodologies
was buggy. Most architectures dropped linuxthreads years ago.
Dave
--
John David Anglin dave.anglin@xxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
