[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#691371: marked as done (Broken COPY relocation with UNIQUE symbols (upstream #12510))

Your message dated Thu, 17 Dec 2015 19:47:47 +0100
with message-id <20151217184747.GA16848@aurel32.net>
and subject line Re: Bug#691371: Broken COPY relocation with UNIQUE symbols (upstream #12510)
has caused the Debian Bug report #691371,
regarding Broken COPY relocation with UNIQUE symbols (upstream #12510)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
691371: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691371
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: libc6
Version: 2.13-35

I just rediscovered http://sourceware.org/bugzilla/show_bug.cgi?id=12510 in my application. Fixed by http://sourceware.org/git/?p=glibc.git;a=commit;h=028478fa40d85a73b19638dbe3f83b1acebf370c

Attached is the test-case I came up with before I found the commit that fixes it, and then the upstream bug.

This is a regression in wheezy vs squeeze; gcc in squeeze didn't generate UNIQUE symbols (at least for this case), AND the old dynamic linker seems to not have this bug.

The actual code part of that upstream patch applies cleanly to wheezy's libc and fixes the problem. ISTM that it'd be a good idea to backport, given that wheezy isn't going to upgrade to a new upstream release.

==== test.h ====
template<typename X>
class Foo {
public:
    static const char foo[];
};

==== test1.cpp ====
#include "test.h"

// Creates a UNIQUE symbol (and thus hits dynamic linker bug), used to
// create a WEAK symbol instead.
template<typename X>
const char Foo<X>::foo[] = "string";
template class Foo<int>;

const char * getone() {
    // Creates a R_X86_64_GLOB_DAT relocation
    return Foo<int>::foo;
}

==== test2.cpp ====
#include "test.h"
#include <stdio.h>
#include <string.h>

int main() {
    // Reference creates a R_X86_64_COPY relocation
    if (strcmp(Foo<int>::foo, "string")) {
	printf("'%s'\n", Foo<int>::foo);
        return 1;
    }
    return 0;
}


==== test.sh ====
g++ -fPIC -shared -o test.so test1.cpp
g++ -o test test2.cpp ./test.so
./test

--- End Message ---
--- Begin Message --- 
Version: 2.17-1

On 2012-10-24 16:12, James Y Knight wrote:
> Package: libc6
> Version: 2.13-35
> 
> I just rediscovered http://sourceware.org/bugzilla/show_bug.cgi?id=12510 in my application. Fixed by http://sourceware.org/git/?p=glibc.git;a=commit;h=028478fa40d85a73b19638dbe3f83b1acebf370c
> 
> Attached is the test-case I came up with before I found the commit that fixes it, and then the upstream bug.
> 
> This is a regression in wheezy vs squeeze; gcc in squeeze didn't generate UNIQUE symbols (at least for this case), AND the old dynamic linker seems to not have this bug.
> 
> The actual code part of that upstream patch applies cleanly to wheezy's libc and fixes the problem. ISTM that it'd be a good idea to backport, given that wheezy isn't going to upgrade to a new upstream release.
> 
> ==== test.h ====
> template<typename X>
> class Foo {
> public:
>     static const char foo[];
> };
> 
> ==== test1.cpp ====
> #include "test.h"
> 
> // Creates a UNIQUE symbol (and thus hits dynamic linker bug), used to
> // create a WEAK symbol instead.
> template<typename X>
> const char Foo<X>::foo[] = "string";
> template class Foo<int>;
> 
> const char * getone() {
>     // Creates a R_X86_64_GLOB_DAT relocation
>     return Foo<int>::foo;
> }
> 
> ==== test2.cpp ====
> #include "test.h"
> #include <stdio.h>
> #include <string.h>
> 
> int main() {
>     // Reference creates a R_X86_64_COPY relocation
>     if (strcmp(Foo<int>::foo, "string")) {
> 	printf("'%s'\n", Foo<int>::foo);
>         return 1;
>     }
>     return 0;
> }
> 
> 
> ==== test.sh ====
> g++ -fPIC -shared -o test.so test1.cpp
> g++ -o test test2.cpp ./test.so
> ./test

This bug has been fixed in upstream glibc 2.14. I am therefore closing
the bug.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

--- End Message ---
Reply to: