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. Eike
Attachment:
signature.asc
Description: This is a digitally signed message part.
