Re: glibc updated

[Rolf Eike Beer <eike-kernel@sf-tec.de>]

[-- Attachment #1: Type: text/plain, Size: 3435 bytes --]

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 #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]