NetBSD Problem Report #48324
From www@NetBSD.org Fri Oct 18 23:02:55 2013
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK))
by mollari.NetBSD.org (Postfix) with ESMTPS id 02443726BF
for <gnats-bugs@gnats.NetBSD.org>; Fri, 18 Oct 2013 23:02:55 +0000 (UTC)
Message-Id: <20131018230252.BAD8D72779@mollari.NetBSD.org>
Date: Fri, 18 Oct 2013 23:02:52 +0000 (UTC)
From: nathanialsloss@yahoo.com.au
Reply-To: nathanialsloss@yahoo.com.au
To: gnats-bugs@NetBSD.org
Subject: ld.elf_so - tty.c memcpy overwrites tcb for tls variant 2
X-Send-Pr-Version: www-1.0
>Number: 48324
>Category: lib
>Synopsis: ld.elf_so - tty.c memcpy overwrites tcb for tls variant 2
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: lib-bug-people
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Oct 18 23:05:00 +0000 2013
>Closed-Date: Fri Nov 08 08:08:54 +0000 2013
>Last-Modified: Fri Nov 08 08:08:54 +0000 2013
>Originator: Nat Sloss
>Release: NetBSD 6.1.1
>Organization:
>Environment:
NetBSD test 6.1.1_PATCH NetBSD 6.1.1_PATCH (HPMICROSERVER) #1: Fri Sep 27 19:34:11 EST 2013 build@test:/usr/src/sys/arch/i386/compile/obj/HPMICROSERVER i386
>Description:
Hi Ive found that the package I'm building calligra which has an indirect dependency on libmpfr (whch is built with TLS support) hangs whilst loading.
Upon further investigation I've found that the tlsinit block over writes the tcb for TLS variant 2. TLS variant 1 is ok because tlsinit is copied to memory above the tcb.
From what I've read so far the tls images are copied to memory below the tcb but I don't think the should overwrite the tcb.
>How-To-Repeat:
Try loading a programme that uses libmpfr TLS enabled on a machine with TLS variant 2 and it should crash or hang.
>Fix:
From what I've read the memory layout for TLS variant 2 should be:
image 2, image 1, tlsinit, tcb.
So the fix would be to apply this patch:
Index: src/libexec/ld.elf_so/tls.c
===================================================================
RCS file: /cvsroot/src/libexec/ld.elf_so/tls.c,v
retrieving revision 1.7
diff -u -r1.7 tls.c
--- src/libexec/ld.elf_so/tls.c 23 Apr 2011 16:40:08 -0000 1.7
+++ src/libexec/ld.elf_so/tls.c 18 Oct 2013 05:08:26 -0000
@@ -142,7 +142,7 @@
#ifdef __HAVE_TLS_VARIANT_I
q = p + obj->tlsoffset;
#else
- q = p - obj->tlsoffset;
+ q = p - obj->tlsoffset - obj->tlsinitsize;
#endif
memcpy(q, obj->tlsinit, obj->tlsinitsize);
tcb->tcb_dtv[obj->tlsindex] = q;
then the image would be before the tcb and would not overwrite it.
I've tested this in gdb and it works well.
I was just wondering if implementing this change to ld.elf_so whether I'd have to rebuild the system/packages or only ld.elf_so.
Regards,
Nat.
>Release-Note:
>Audit-Trail:
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: lib/48324: ld.elf_so - tty.c memcpy overwrites tcb for tls
variant 2
Date: Sat, 19 Oct 2013 05:52:24 +0000
On Fri, Oct 18, 2013 at 11:05:00PM +0000, nathanialsloss@yahoo.com.au wrote:
> I was just wondering if implementing this change to ld.elf_so
> whether I'd have to rebuild the system/packages or only ld.elf_so.
Just ld.elf_so - it's a dynamically loaded image. But be careful
tinkering with it, as if you install a bad one you're fairly well in
the soup.
--
David A. Holland
dholland@netbsd.org
From: Nick Hudson <nick.hudson@gmx.co.uk>
To: gnats-bugs@NetBSD.org, lib-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: lib/48324: ld.elf_so - tty.c memcpy overwrites tcb for tls variant
2
Date: Sat, 19 Oct 2013 11:17:29 +0100
On 19/10/2013 00:05, nathanialsloss@yahoo.com.au wrote:
>> Number: 48324
>> Synopsis: ld.elf_so - tty.c memcpy overwrites tcb for tls variant 2
[...]
>> - q = p - obj->tlsoffset;
>> + q = p - obj->tlsoffset - obj->tlsinitsize;
>>
I'm not convinced this is correct.
I've just committed some debug code to ld.elf_so to help understand
what's going on here. Can you build a -DDEBUG -DRTLD_DEBUG ld.elf_so and
run your test problem against it (the environment variable LD_DEBUG
needs to be set)
Typically I create a ld.dbg_so and point the program at that so I don't
hose my system.
Thanks,
Nick
From: Nat Sloss <nathanialsloss@yahoo.com.au>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: lib/48324: ld.elf_so - tty.c memcpy overwrites tcb for tls variant 2
Date: Sat, 19 Oct 2013 22:35:17 +1100
Hi
> Typically I create a ld.dbg_so and point the program at that so I don't
> hose my system.
How do I point the program at the debug ld_elf.so (I've updated the sources,
set the build flags and built it.)
I tried using LD_PRELOAD but that caused the program to dump its core.
Regards,
Nat.
From: Nick Hudson <nick.hudson@gmx.co.uk>
To: gnats-bugs@NetBSD.org, lib-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
nathanialsloss@yahoo.com.au
Cc:
Subject: Re: lib/48324: ld.elf_so - tty.c memcpy overwrites tcb for tls variant
2
Date: Sat, 19 Oct 2013 13:21:57 +0100
On 19/10/2013 13:05, Nat Sloss wrote:
> The following reply was made to PR lib/48324; it has been noted by GNATS.
>
> From: Nat Sloss <nathanialsloss@yahoo.com.au>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: lib/48324: ld.elf_so - tty.c memcpy overwrites tcb for tls variant 2
> Date: Sat, 19 Oct 2013 22:35:17 +1100
>
> Hi
> > Typically I create a ld.dbg_so and point the program at that so I don't
> > hose my system.
>
> How do I point the program at the debug ld_elf.so (I've updated the sources,
> set the build flags and built it.)
Use your favourite editor to change the program. You could relink using
--dynamic-linker= , but that's probably harder
Nick
From: Nat Sloss <nathanialsloss@yahoo.com.au>
To: Nick Hudson <nick.hudson@gmx.co.uk>
Cc: gnats-bugs@netbsd.org
Subject: Re: lib/48324: ld.elf_so - tty.c memcpy overwrites tcb for tls variant 2
Date: Sun, 20 Oct 2013 07:53:57 +1100
On Sun, 20 October 2013 02:45:38 you wrote:
> On 19/10/2013 13:58, Nat Sloss i wrote:
> > obj 0xb3877800 dtv 0xb82e5a40 tlsoffset 0
>
> A tlsoffset of 0 is wrong. Looks like we're missing a call to
> _rtld_tls_offset_allocate somewhere.
>
> Nick
I have found using gdb that obj->tls_done = 0. This was found whilst in
rtld_allocate_locked.
Should tls storage have been initialized previously for libmpfr. ldd on the
program makes no reference to libmpfr, its a dependency for one of the
libraries which is listed by ldd libsoprano.
If tls storage is not initialized may we initialize it during allocation. ie:
Index: ld.elf_so/tls.c
===================================================================
RCS file: /cvsroot/src/libexec/ld.elf_so/tls.c,v
retrieving revision 1.8
diff -u -r1.8 tls.c
--- ld.elf_so/tls.c 19 Oct 2013 10:14:06 -0000 1.8
+++ ld.elf_so/tls.c 19 Oct 2013 21:18:26 -0000
@@ -141,6 +141,11 @@
SET_DTV_GENERATION(tcb->tcb_dtv, _rtld_tls_dtv_generation);
for (obj = _rtld_objlist; obj != NULL; obj = obj->next) {
+ if (obj->tls_done == 0) {
+ if (rtld_tls_offset_allocate(obj) < 0)
+ continue;
+ }
+
if (obj->tlssize) {
#ifdef __HAVE_TLS_VARIANT_I
q = p + obj->tlsoffset;
I don't know if it was a good idea to skip tls modules that could not be
initialized.
Regards,
Nat.
From: Nat Sloss <nathanialsloss@yahoo.com.au>
To: gnats-bugs@netbsd.org
Cc: Nick Hudson <nick.hudson@gmx.co.uk>
Subject: Re: lib/48324: ld.elf_so - tty.c memcpy overwrites tcb for tls variant 2
Date: Sun, 20 Oct 2013 12:04:34 +1100
Hi,
I think that even if I was to call tls_offset_allocate the tls module wont
load.
Due to this in tls.c _ttld_tls_offset_allocate:
if (_rtld_tls_static_space) {
if (obj->tlsinitsize) {
_rtld_error("%s: Use of initialized "
"Thread Local Storage with model initial-exec "
"and dlopen is not supported",
obj->path);
return -1;
}
I know from gdb that the _rtkd_tls_static_space has a value of 0x40 and
obj->tlssize = 0x6c. So it would return an error and not set the offset.
I am not sure if my package will run correctly is there any way I could load
mpfr earlier so it would be initialised in the first call to
_rtld_tls_offset_allocate maybe using RTLD_NOW or I can just use the package
having built mpfr without TLS support.
Regards,
Nat.
From: Nat Sloss <nathanialsloss@yahoo.com.au>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: lib/48324: ld.elf_so - tty.c memcpy overwrites tcb for tls variant 2
Date: Sun, 20 Oct 2013 18:39:08 +1100
Hi.
I've been doing more reading and I think that the TLS model libmpfr was built
with is dynamic I've been experimenting with -ftls-model with
model=initial-exec it seems to run but then seg faults when loading but at
least it doesn't freeze.
I was wondering what the tls optimization switches I should specify for 6.1.1
i386 kernel.
I'd did not specify the tls model initially when building libmpfr and it would
hang and give me the results documented in this PR.
Regards,
Nat.
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: lib/48324: ld.elf_so - tty.c memcpy overwrites tcb for tls variant 2
Date: Sun, 20 Oct 2013 11:44:27 +0200
On Sun, Oct 20, 2013 at 01:35:00AM +0000, Nat Sloss wrote:
> I am not sure if my package will run correctly is there any way I could load
> mpfr earlier so it would be initialised in the first call to
> _rtld_tls_offset_allocate maybe using RTLD_NOW
I don't think there is anything to this effect beside LD_PRELOAD (e.g.
creating a wrapper shell script...)
It would be super helpfull if you could create a minimalistic set of
"hello world" style shared libs and main application reproducing the
failure from sources, which we could use to verify a fix and as base
for a later regression test.
Thanks,
Martin
From: Nat Sloss <nathanialsloss@yahoo.com.au>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: lib/48324: ld.elf_so - tty.c memcpy overwrites tcb for tls variant 2
Date: Mon, 21 Oct 2013 00:02:29 +1100
Hi.
> It would be super helpfull if you could create a minimalistic set of
> "hello world" style shared libs and main application reproducing the
> failure from sources, which we could use to verify a fix and as base
> for a later regression test.
Unfortunately the test I'm trying to writ succeeds and I've just created a
sourceforge account and have been added to pkgsrc-wip.
I have an updated version of calligra which I'm about three days away from
committing of which calligra words and calligraauthor exhibit the failure.
So I can only supply back traces and information from gdb until I commit the
package and others can test it.
However I have found something interesting from the back trace of the hung
process.
The backtrace is as follows:
#0 0xbb7f904b in _rtld_tls_allocate_locked ()
at /home/build/NetBSD-6.1_source_tree/usr/src/libexec/ld.elf_so/tls.c:148
#1 0xbb7f9088 in _rtld_tls_allocate ()
at /home/build/NetBSD-6.1_source_tree/usr/src/libexec/ld.elf_so/tls.c:162
#2 0xb8c4c799 in pthread_create (thread=0xb3272cb4, attr=0xbf7fda48,
startfunc=0xb9521342 <QThreadPrivate::start(void*)>, arg=0xb327bf60)
at /home/build/NetBSD-6.1_source_tree/usr/src/lib/libpthread/pthread.c:430
#3 0xb9521780 in QThread::start (this=0xb327bf60,
priority=QThread::InheritPriority) at thread/qthread_unix.cpp:640
#4 0xb9603edc in QKqueueFileSystemWatcherEngine::addPaths (this=0xb327bf60,
paths=..., files=0xb32922b8, directories=0xb32922bc)
at io/qfilesystemwatcher_kqueue.cpp:196
#5 0xb95f4574 in QFileSystemWatcher::addPaths (this=0xb73ff790, paths=...)
at io/qfilesystemwatcher.cpp:545
#6 0xb95f4fc3 in QFileSystemWatcher::addPath (this=0xb73ff790, path=...)
at io/qfilesystemwatcher.cpp:486
#7 0xb990f15a in KDirWatchPrivate::useQFSWatch (this=0xb739b600,
e=0xb329a794)
at /home/packages/2013Q2/pkgsrc/x11/kdelibs4/work/kdelibs-4.10.3/kdecore/io/kdirwatch.cpp:717
#8 0xb990e1ff in KDirWatchPrivate::addWatch (this=0xb739b600, e=0xb329a794)
at /home/packages/2013Q2/pkgsrc/x11/kdelibs4/work/kdelibs-4.10.3/kdecore/io/kdirwatch.cpp:934
What is interesting is pthread.c:430 revision 1.125.4.3
There is a call to rtld_tls_allocate without a proceeding call to
_rtld_tls_offset_allocate and i know that the tls_static_space is the minimum
64 bytes and the tlsoffset is zero. So would a call to tls_allocate_offset
fix the problem.
Would that be appropriate?
And to successfully create an example of the failure I'd have to know under
what circumstances creating a thread that would then load tls data from a
shared library that was not previously allocated/initialized.
Regards,
Nat.
From: Nick Hudson <nick.hudson@gmx.co.uk>
To: gnats-bugs@NetBSD.org, lib-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
nathanialsloss@yahoo.com.au
Cc:
Subject: Re: lib/48324: ld.elf_so - tty.c memcpy overwrites tcb for tls variant
2
Date: Sun, 20 Oct 2013 14:57:25 +0100
On 20/10/2013 14:35, Nat Sloss wrote:
> The following reply was made to PR lib/48324; it has been noted by GNATS.
>
> From: Nat Sloss <nathanialsloss@yahoo.com.au>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: lib/48324: ld.elf_so - tty.c memcpy overwrites tcb for tls variant 2
> Date: Mon, 21 Oct 2013 00:02:29 +1100
>
> Hi.
> > It would be super helpfull if you could create a minimalistic set of
> > "hello world" style shared libs and main application reproducing the
> > failure from sources, which we could use to verify a fix and as base
> > for a later regression test.
>
> Unfortunately the test I'm trying to writ succeeds and I've just created a
> sourceforge account and have been added to pkgsrc-wip.
Pretty sure we have a minimal test case now with the following change
http://www.netbsd.org/~skrll/h_tls_dlopen.c.diff
<http://www.netbsd.org/%7Eskrll/h_tls_dlopen.c.diff>
Nick
From: Nat Sloss <nathanialsloss@yahoo.com.au>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: lib/48324: ld.elf_so - tty.c memcpy overwrites tcb for tls variant 2
Date: Mon, 21 Oct 2013 07:39:48 +1100
Hi.
> Pretty sure we have a minimal test case now with the following change
>
> http://www.netbsd.org/~skrll/h_tls_dlopen.c.diff
> <http://www.netbsd.org/%7Eskrll/h_tls_dlopen.c.diff>
>
> Nick
The new test failed and here's the results:
Tests root: /tmp/tls
t_tls_static (1/3): 1 test cases
t_tls_static: [0.115739s] Passed.
[0.183923s]
t_tls_dynamic (2/3): 1 test cases
t_tls_dynamic: [0.119721s] Passed.
[0.187352s]
t_tls_dlopen (3/3): 1 test cases
t_tls_dlopen: [0.248944s] Failed: Test program received signal 11 (core
dumped)
[0.334807s]
Failed test cases:
t_tls_dlopen:t_tls_dlopen
Summary for 3 test programs:
2 passed test cases.
1 failed test cases.
0 expected failed test cases.
0 skipped test cases.
I was just wondering where the coredump was written to, so I can do a
backtrace in gdb and verify it is the same problem.
Regards,
Nat.
From: Nat Sloss <nathanialsloss@yahoo.com.au>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: lib/48324: ld.elf_so - tty.c memcpy overwrites tcb for tls variant 2
Date: Mon, 21 Oct 2013 08:14:17 +1100
Hi.
Ive gone through the new atf tls dlopen test with gdb and the call to rtld_tls
allocate (the last one before the test segfaults exhibits) the same
behaviour.
obj->tlsoffset == 0, obj->tls_done == 0;
Regards,
Nat.
From: Nat Sloss <nathanialsloss@yahoo.com.au>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: lib/48324: ld.elf_so - tty.c memcpy overwrites tcb for tls variant 2
Date: Mon, 21 Oct 2013 12:25:23 +1100
Hi.
I was trying many things to get it passed the atf tls dlopen test.
It turns out if you declare var4 as __thread volatile var4 = 1 it passes.
So I guess it has something to do with compiler optimization.
So I patched the define containing __thread with __thread volatile in libmpfr
and all is well. So I don't think that ld.elf_so/libpthread needs changing.
Thank you to everyone who worked on this.
Should I submit another PR with the changes to the mpfr package or should I
deal with it here?
Regards,
Nat.
From: Nat Sloss <nathanialsloss@yahoo.com.au>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: lib/48324: ld.elf_so - tty.c memcpy overwrites tcb for tls variant 2
Date: Mon, 21 Oct 2013 13:16:10 +1100
Hi.
I changed the src/tests/lib/libc/tls/dso/Makefile, adding CFLAGS=-O0 to
disable optimization and built the tests using __thread int var4 = 1.
Then I ran the test and the process froze and had to be killed.
So I ran it again and used gdb on the process and I found that it was in the
same place as the debugging of calligrawords with the same values for
variables. So for testing where it stops its better to disable optimization
in the Makefile for the libraries used for the tls dlopen test.
Regards,
Nat.
From: Nick Hudson <nick.hudson@gmx.co.uk>
To: gnats-bugs@NetBSD.org, lib-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
nathanialsloss@yahoo.com.au
Cc:
Subject: Re: lib/48324: ld.elf_so - tty.c memcpy overwrites tcb for tls variant
2
Date: Mon, 21 Oct 2013 07:46:17 +0100
On 21/10/2013 02:55, Nat Sloss wrote:
[...]
> It turns out if you declare var4 as __thread volatile var4 = 1 it passes.
>
> So I guess it has something to do with compiler optimization.
>
> So I patched the define containing __thread with __thread volatile in libmpfr
> and all is well. So I don't think that ld.elf_so/libpthread needs changing.
ld.elf_so need fixiing.
>
> Thank you to everyone who worked on this.
>
> Should I submit another PR with the changes to the mpfr package or should I
> deal with it here?
Probably best a send PR.
Nick
From: Nat Sloss <nathanialsloss@yahoo.com.au>
To: Nick Hudson <nick.hudson@gmx.co.uk>
Cc: gnats-bugs@netbsd.org
Subject: Re: lib/48324: ld.elf_so - tty.c memcpy overwrites tcb for tls variant 2
Date: Mon, 21 Oct 2013 17:42:23 +1100
Hi.
Thanks for letting me know.
I won't change libmpfr.
Regards,
Nat.
From: "Joerg Sonnenberger" <joerg@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/48324 CVS commit: src
Date: Mon, 21 Oct 2013 19:14:16 +0000
Module Name: src
Committed By: joerg
Date: Mon Oct 21 19:14:16 UTC 2013
Modified Files:
src/libexec/ld.elf_so: tls.c
src/tests/lib/libc/tls/dso: h_tls_dlopen.c
Log Message:
Only initialise TLS space from the PT_TLS segment, if the size is
positive and the offset has been computed. Fixes PR lib/48324.
To generate a diff of this commit:
cvs rdiff -u -r1.8 -r1.9 src/libexec/ld.elf_so/tls.c
cvs rdiff -u -r1.4 -r1.5 src/tests/lib/libc/tls/dso/h_tls_dlopen.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Nat Sloss <nathanialsloss@yahoo.com.au>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: PR/48324 CVS commit: src
Date: Tue, 22 Oct 2013 08:44:07 +1100
Hi,
I've tested the new ld.elf_so and the atf tests pass and calligrawords and
calligraauthor now run with a tls enabled libmpfr.
I would also like to ask that NetBSD-6 be pulled up.
I would like to thank all responsible for testing, committing and analysing
code.
Regards,
Nat.
From: Nat Sloss <nathanialsloss@yahoo.com.au>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: lib/48324 CVS commit: src
Date: Tue, 22 Oct 2013 09:14:03 +1100
---------- Forwarded Message ----------
Subject: Re: PR/48324 CVS commit: src
Date: Tue, 22 October 2013
Hi,
I've tested the new ld.elf_so and the atf tests pass and calligrawords and
calligraauthor now run with a tls enabled libmpfr.
I would also like to ask that NetBSD-6 be pulled up.
I would like to thank all responsible for testing, committing and analysing
code.
Regards,
Nat.
-------------------------------------------------------
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: lib/48324: ld.elf_so - tty.c memcpy overwrites tcb for tls
variant 2
Date: Sat, 2 Nov 2013 19:40:08 +0000
not sent to gnats
------
From: Nick Hudson <nick.hudson@gmx.co.uk>
To: lib-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
nathanialsloss@yahoo.com.au
Subject: Re: lib/48324: ld.elf_so - tty.c memcpy overwrites tcb for tls variant
2
Date: Mon, 21 Oct 2013 08:01:59 +0100
On 21/10/2013 07:50, Nick Hudson wrote:
[...]
> > Should I submit another PR with the changes to the mpfr package or should I
> > deal with it here?
> Probably best a send PR.
Actually, I just had a quick look and I don't think libmpfr is at
fault at all here.
Nick
From: "Soren Jacobsen" <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/48324 CVS commit: [netbsd-6] src
Date: Thu, 7 Nov 2013 20:23:46 +0000
Module Name: src
Committed By: snj
Date: Thu Nov 7 20:23:46 UTC 2013
Modified Files:
src/libexec/ld.elf_so [netbsd-6]: tls.c
src/tests/lib/libc/tls/dso [netbsd-6]: h_tls_dlopen.c
Log Message:
Pull up following revision(s) (requested by joerg in ticket #976):
libexec/ld.elf_so/tls.c: revision 1.9
tests/lib/libc/tls/dso/h_tls_dlopen.c: revision 1.5
Only initialise TLS space from the PT_TLS segment, if the size is
positive and the offset has been computed. Fixes PR lib/48324.
To generate a diff of this commit:
cvs rdiff -u -r1.7 -r1.7.6.1 src/libexec/ld.elf_so/tls.c
cvs rdiff -u -r1.4 -r1.4.2.1 src/tests/lib/libc/tls/dso/h_tls_dlopen.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Soren Jacobsen" <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/48324 CVS commit: [netbsd-6-0] src
Date: Thu, 7 Nov 2013 20:31:55 +0000
Module Name: src
Committed By: snj
Date: Thu Nov 7 20:31:55 UTC 2013
Modified Files:
src/libexec/ld.elf_so [netbsd-6-0]: tls.c
src/tests/lib/libc/tls/dso [netbsd-6-0]: h_tls_dlopen.c
Log Message:
Pull up following revision(s) (requested by joerg in ticket #976):
libexec/ld.elf_so/tls.c: revision 1.9
tests/lib/libc/tls/dso/h_tls_dlopen.c: revision 1.5
Only initialise TLS space from the PT_TLS segment, if the size is
positive and the offset has been computed. Fixes PR lib/48324.
To generate a diff of this commit:
cvs rdiff -u -r1.7 -r1.7.12.1 src/libexec/ld.elf_so/tls.c
cvs rdiff -u -r1.4 -r1.4.8.1 src/tests/lib/libc/tls/dso/h_tls_dlopen.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Soren Jacobsen" <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/48324 CVS commit: [netbsd-6-1] src
Date: Thu, 7 Nov 2013 20:32:37 +0000
Module Name: src
Committed By: snj
Date: Thu Nov 7 20:32:37 UTC 2013
Modified Files:
src/libexec/ld.elf_so [netbsd-6-1]: tls.c
src/tests/lib/libc/tls/dso [netbsd-6-1]: h_tls_dlopen.c
Log Message:
Pull up following revision(s) (requested by joerg in ticket #976):
libexec/ld.elf_so/tls.c: revision 1.9
tests/lib/libc/tls/dso/h_tls_dlopen.c: revision 1.5
Only initialise TLS space from the PT_TLS segment, if the size is
positive and the offset has been computed. Fixes PR lib/48324.
To generate a diff of this commit:
cvs rdiff -u -r1.7 -r1.7.18.1 src/libexec/ld.elf_so/tls.c
cvs rdiff -u -r1.4 -r1.4.14.1 src/tests/lib/libc/tls/dso/h_tls_dlopen.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Fri, 08 Nov 2013 08:08:54 +0000
State-Changed-Why:
pullups done, thanks
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home