Hi,
I want to add following cleanup patch. No regressions found.
Okay? Comments?
best regards Waldemar
Hi Waldemar,
On Sun, Jul 10, 2016 at 9:25 AM, Waldemar Brodkorb wbx@uclibc-ng.org wrote:
I want to add following cleanup patch. No regressions found.
Okay? Comments?
The following looks either broken or unused in the current code, given there's no matching PTR_MANGLE:
diff --git a/libc/sysdeps/linux/x86_64/sched_getcpu.S b/libc/sysdeps/linux/x86_64/sched_getcpu.S index f8c09c0..1e0a344 100644 --- a/libc/sysdeps/linux/x86_64/sched_getcpu.S +++ b/libc/sysdeps/linux/x86_64/sched_getcpu.S @@ -37,7 +37,6 @@ ENTRY (sched_getcpu)
#ifdef SHARED movq __vdso_getcpu(%rip), %rax - PTR_DEMANGLE (%rax) callq *%rax #else # ifdef __NR_getcpu
AFAICS PTR_MANGLE/PTR_DEMANGLE are still present in glibc, but their use in common code is conditional, though in arch-specific code it is not.
Do you plan for syncing with glibc in the future?
Hi Max, Max Filippov wrote,
Hi Waldemar,
On Sun, Jul 10, 2016 at 9:25 AM, Waldemar Brodkorb wbx@uclibc-ng.org wrote:
I want to add following cleanup patch. No regressions found.
Okay? Comments?
The following looks either broken or unused in the current code, given there's no matching PTR_MANGLE:
Right. Is SHARED defined via gcc? I think normally #ifdef __PIC__ is used for this?
diff --git a/libc/sysdeps/linux/x86_64/sched_getcpu.S b/libc/sysdeps/linux/x86_64/sched_getcpu.S index f8c09c0..1e0a344 100644 --- a/libc/sysdeps/linux/x86_64/sched_getcpu.S +++ b/libc/sysdeps/linux/x86_64/sched_getcpu.S @@ -37,7 +37,6 @@ ENTRY (sched_getcpu)
#ifdef SHARED movq __vdso_getcpu(%rip), %rax
- PTR_DEMANGLE (%rax) callq *%rax
#else # ifdef __NR_getcpu
AFAICS PTR_MANGLE/PTR_DEMANGLE are still present in glibc, but their use in common code is conditional, though in arch-specific code it is not.
Do you plan for syncing with glibc in the future?
Not really. I will do partially sync architecture specific bits and bytes. But no bigger sync is planned.
best regards Waldemar
On Mon, Jul 11, 2016 at 9:13 AM, Waldemar Brodkorb wbx@uclibc-ng.org wrote:
Max Filippov wrote,
On Sun, Jul 10, 2016 at 9:25 AM, Waldemar Brodkorb wbx@uclibc-ng.org wrote:
I want to add following cleanup patch. No regressions found.
Okay? Comments?
The following looks either broken or unused in the current code, given there's no matching PTR_MANGLE:
Right. Is SHARED defined via gcc?
I think it comes from the following line in the Makerules:
CFLAGS-.oS+=$(PICFLAG) -DSHARED
I think normally #ifdef __PIC__ is used for this?
Does that work for FDPIC or shared FLAT?
Do you plan for syncing with glibc in the future?
Not really. I will do partially sync architecture specific bits and bytes. But no bigger sync is planned.
Ok. Reviewed-by: Max Filippov jcmvbkbc@gmail.com
Hi Max, Max Filippov wrote,
On Mon, Jul 11, 2016 at 9:13 AM, Waldemar Brodkorb wbx@uclibc-ng.org wrote:
Max Filippov wrote,
On Sun, Jul 10, 2016 at 9:25 AM, Waldemar Brodkorb wbx@uclibc-ng.org wrote:
I want to add following cleanup patch. No regressions found.
Okay? Comments?
The following looks either broken or unused in the current code, given there's no matching PTR_MANGLE:
Right. Is SHARED defined via gcc?
I think it comes from the following line in the Makerules:
CFLAGS-.oS+=$(PICFLAG) -DSHARED
So it does not apply to .os and so we found indeed dead code. The referenced function isn't there, I will remove the code inside SHARED.
I think normally #ifdef __PIC__ is used for this?
Does that work for FDPIC or shared FLAT?
For FDPIC, yes: ./toolchain_sim-bfin_uclibc-ng_bf512_fdpic/usr/bin/bfin-openadk-linux-uclibc-gcc -dM -E - < /dev/null|grep -i pic #define __BFIN_FDPIC__ 1 #define __pic__ 1 #define __PIC__ 1 #define __FDPIC__ 1
For shared FLAT, no: ./toolchain_sim-bfin_uclibc-ng_bf512_bflt/usr/bin/bfin-openadk-uclinux-uclibc-gcc -dM -E - </dev/null|grep -i pic
So indeed normally __PIC__ should be fine for architectures without MMU-less support, rigth?
Do you plan for syncing with glibc in the future?
Not really. I will do partially sync architecture specific bits and bytes. But no bigger sync is planned.
Ok. Reviewed-by: Max Filippov jcmvbkbc@gmail.com
Thanks Waldemar
-
Max Filippov -
Waldemar Brodkorb