cleanup patch PTR_MANGLE/PTR_DEMANGLE
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? -- Thanks. -- Max
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> -- Thanks. -- Max
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
participants (2)
-
Max Filippov -
Waldemar Brodkorb