[RFC][PATCH] dl-string.h: define _dl_strchr and _dl_strstr if not IS_IN_rtld

2015-03-31 Thread Junling Zheng
: undefined reference to `_dl_strchr' So, add the definition of _dl_strchr and _dl_strstr. Signed-off-by: Junling Zheng zhengjunl...@huawei.com --- ldso/include/dl-string.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ldso/include/dl-string.h b/ldso/include/dl-string.h index aacad10..14ae617

[RFC] [PATCH] ldso: limited support for $ORIGIN in rpath

2015-04-03 Thread Junling Zheng
at iki.fi Signed-off-by: Junling Zheng zhengjunl...@huawei.com --- ldso/include/dl-string.h | 2 ++ ldso/ldso/dl-elf.c | 79 +--- ldso/ldso/ldso.c | 18 +-- 3 files changed, 59 insertions(+), 40 deletions(-) diff --git a/ldso

Does this is a loss of precision when using decimal floating types in GDB?

2015-04-28 Thread Junling Zheng
Hi, all When testing gdb in uClibc, a testcase(gdb-7.6/gdb/testsuite/gdb.base/dfp-exprs.exp) failed at: 166 gdb_test p (_Decimal64) 3.1 = 3.(0999.*|1000.*) And we got some unexpected results: 1) For most numbers, the trailing 0 will be left out: (gdb) p (_Decimal64) 3.1 $1 = 3.1 (gdb) p

Re: Does this is a loss of precision when using decimal floating types in GDB?

2015-05-04 Thread Junling Zheng
Ping. Does anybody have some ideas? Cheer, Junling On 2015/4/28 15:44, Junling Zheng wrote: Hi, all When testing gdb in uClibc, a testcase(gdb-7.6/gdb/testsuite/gdb.base/dfp-exprs.exp) failed at: 166 gdb_test p (_Decimal64) 3.1 = 3.(0999.*|1000.*) And we got some unexpected

Re: Question: Does uclibc support NPTL TLS ?

2015-05-28 Thread Junling Zheng
On 2015/5/29 10:08, Rich Felker wrote: On Fri, May 29, 2015 at 09:58:31AM +0800, Junling Zheng wrote: On 2015/5/29 3:27, Bernhard Reutner-Fischer wrote: On 28 May 2015 at 04:00, Khem Raj raj.k...@gmail.com wrote: Seems like gdb is not able to comprehend the TLS structure that uclibc

Re: Question: Does uclibc support NPTL TLS ?

2015-05-28 Thread Junling Zheng
On 2015/5/29 3:27, Bernhard Reutner-Fischer wrote: On 28 May 2015 at 04:00, Khem Raj raj.k...@gmail.com wrote: Seems like gdb is not able to comprehend the TLS structure that uclibc is putting. So you need to investigate that part, either gdb or libthread-db may be where the issue lies.

Re: [RFC PATCH] nptl_db/db_info: fix the incorrect initial size for dtvp

2015-07-31 Thread Junling Zheng
Ping... On 2015/7/20 21:33, Junling Zheng wrote: When debugging a program on ARMv7 with thread-local storage declared using __thread, attempting to print a thread-local variable will result in the following message: Cannot find thread-local storage for Thread snip (LWP snip), executable

Re: [RFC PATCH] nptl_db/db_info: fix the incorrect initial size for dtvp

2015-08-06 Thread Junling Zheng
Ping again... This patch fixed the following issue: http://lists.uclibc.org/pipermail/uclibc/2015-May/048966.html Does anybody suffer this problem ? On 2015/7/31 18:37, Junling Zheng wrote: Ping... On 2015/7/20 21:33, Junling Zheng wrote: When debugging a program on ARMv7 with thread-local

[RFC PATCH] nptl_db/db_info: fix the incorrect initial size for dtvp

2015-07-20 Thread Junling Zheng
;h=416b630981788c1f08e746e19765aa0e5c2a1360 Signed-off-by: Junling Zheng zhengjunl...@huawei.com --- libpthread/nptl_db/db_info.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libpthread/nptl_db/db_info.c b/libpthread/nptl_db/db_info.c index a57a053..159a027 100644

Re: [RFC PATCH] nptl_db/db_info: fix the incorrect initial size for dtvp

2015-09-20 Thread Junling Zheng
On 2015/8/8 16:03, Bernhard Reutner-Fischer wrote: > On August 7, 2015 4:28:10 AM GMT+02:00, Junling Zheng > <zhengjunl...@huawei.com> wrote: >> Ping again... > > Sorry for the delay, will apply the outstanding patches this weekend. Hi, Bernhard I found that uclibc-

Re: [RFC PATCH] nptl_db/db_info: fix the incorrect initial size for dtvp

2015-12-22 Thread Junling Zheng
Ping again...:( On 2015/9/21 9:53, Junling Zheng wrote: > On 2015/8/8 16:03, Bernhard Reutner-Fischer wrote: >> On August 7, 2015 4:28:10 AM GMT+02:00, Junling Zheng >> <zhengjunl...@huawei.com> wrote: >>> Ping again... >> >> Sorry for the delay, will