i386 cleanups
Hi!
These are tiny cleanups you might like. sizes are "logically" long. No, it does not matter on i386.
processor.h makes INIT_TSS look much more readable. [Please tell me applied or rejected]
Pavel
Index: include/asm-i386/posix_types.h
===================================================================
RCS file: /home/cvs/Repository/linux/include/asm-i386/posix_types.h,v retrieving revision 1.1.1.1
asm-i386/posix_types.h +3 -3
@@ -16,9 +16,9 @@typedef unsigned short __kernel_ipc_pid_t ;typedef unsigned short __kernel_uid_t ;typedef unsigned short __kernel_gid_t ; -typedef unsigned int __kernel_size_t ; -typedef int __kernel_ssize_t ; -typedef int __kernel_ptrdiff_t ; +typedef unsigned long __kernel_size_t ; +typedef long __kernel_ssize_t ; +typedef long __kernel_ptrdiff_t ;typedef long __kernel_time_t ;typedef long __kernel_suseconds_t ;typedef long __kernel_clock_t ;
Index: include/asm-i386/processor.h
===================================================================
RCS file: /home/cvs/Repository/linux/include/asm-i386/processor.h,v retrieving revision 1.2
asm-i386/processor.h +5 -13
@@ -365,19 +365,11 @@ { &init_mm, 0, 0, NULL, PAGE_SHARED, VM_READ | VM_WRITE | VM_EXEC, 1, NULL, NULL }#define INIT_TSS { \ - 0,0,/* back_link, __blh */ \ -sizeof (init_stack) + (long ) &init_stack,/* esp0 */ \ - __KERNEL_DS,0 ,/* ss0 */ \ -0 ,0 ,0 ,0 ,0 ,0 ,/* stack1, stack2 */ \ -0 ,/* cr3 */ \ -0 ,0 ,/* eip,eflags */ \ -0 ,0 ,0 ,0 ,/* eax,ecx,edx,ebx */ \ -0 ,0 ,0 ,0 ,/* esp,ebp,esi,edi */ \ -0 ,0 ,0 ,0 ,0 ,0 ,/* es,cs,ss */ \ -0 ,0 ,0 ,0 ,0 ,0 ,/* ds,fs,gs */ \ -__LDT (0 ),0 ,/* ldt */ \ -0 ,INVALID_IO_BITMAP_OFFSET ,/* tace, bitmap */ \ - {~0, } /* ioperm */ \ + esp0: sizeof(init_stack) + (long) &init_stack, \ + ss0: __KERNEL_DS, \ + ldt: __LDT(0), \ + bitmap: INVALID_IO_BITMAP_OFFSET, \ + ioperm: {~0, } \ }#define start_thread (regs, new_eip, new_esp) do { \
Signature · 2 lines
I'm [email protected]. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [email protected]
Quoted 19 lines · Pavel Machek
Hi!
These are tiny cleanups you might like. sizes are "logically" long. No, it does not matter on i386.
processor.hmakesINIT_TSSlook much more readable. [Please tell me applied or rejected]Pavel
Index:
include/asm-i386/posix_types.h
===================================================================
RCS file:/home/cvs/Repository/linux/include/asm-i386/posix_types.h,vretrieving revision 1.1.1.1
diff -u -u -r1.1.1.1posix_types.h
asm-i386/posix_types.h 2001/02/13 13:49:18 line 21
Quoted 9 lines
asm-i386/posix_types.h 2001/02/13 13:49:18 renamed from asm-i386/posix_types.h 2000/09/04 16:50:33 1.1.1.1 +3
-3@@ -16,9 +16,9 @@ typedef unsigned short __kernel_ipc_pid_t; typedef unsigned short __kernel_uid_t; typedef unsigned short __kernel_gid_t; -typedef unsigned int __kernel_size_t; -typedef int __kernel_ssize_t; -typedef int __kernel_ptrdiff_t; +typedef unsigned long __kernel_size_t; +typedef long __kernel_ssize_t; +typedef long __kernel_ptrdiff_t;
If it doesn't matter on i386 why bother?
Quoted 9 lines
asm-i386/posix_types.h 2001/02/13 13:49:18 renamed from asm-i386/posix_types.h 2000/09/04 16:50:33 1.1.1.1 +0
-8#define INIT_TSS { \ - 0,0, /* back_link, __blh */ \ - sizeof(init_stack) + (long) &init_stack, /* esp0 */ \ - __KERNEL_DS, 0, /* ss0 */ \ - 0,0,0,0,0,0, /* stack1, stack2 */ \ - 0, /* cr3 */ \ - 0,0, /* eip,eflags */ \ - 0,0,0,0, /* eax,ecx,edx,ebx */ \ - 0,0,0,0, /* esp,ebp,esi,edi */ \
asm-i386/posix_types.h 2001/02/13 13:49:18
Quoted 10 lines
asm-i386/posix_types.h 2001/02/13 13:49:18 renamed from asm-i386/posix_types.h 2000/09/04 16:50:33 1.1.1.1 +5
-5- 0,0,0,0,0,0, /* es,cs,ss */ \ - 0,0,0,0,0,0, /* ds,fs,gs */ \ - __LDT(0),0, /* ldt */ \ - 0, INVALID_IO_BITMAP_OFFSET, /* tace, bitmap */ \ - {~0, } /* ioperm */ \ + esp0: sizeof(init_stack) + (long) &init_stack, \ + ss0: __KERNEL_DS, \ + ldt: __LDT(0), \ + bitmap: INVALID_IO_BITMAP_OFFSET, \ + ioperm: {~0, } \
IIRC certain key structures cannot be taken to gcc's style of struct initialization, and IIRC this is one of them. Maybe that's a egcs-1.1.2 bug. Have you looked at the assembly output to make sure things are 100% ok after this change?
Regards,
Jeff, who wonders if there is a way to upgrade human memory as easily as computer memory...
Signature · 3 lines
Jeff Garzik | "Give a man a fish, and he eats for a day. Teach a Building 1024 | man to fish, and a US Navy submarine will make sure MandrakeSoft | he's never hungry again." -- Chris Neufeld
Quoted 24 lines · Jeff Garzik
Quoted 22 lines · Pavel Machek
Hi!
These are tiny cleanups you might like. sizes are "logically" long. No, it does not matter on i386.
processor.hmakesINIT_TSSlook much more readable. [Please tell me applied or rejected]Pavel
Index:
include/asm-i386/posix_types.h
===================================================================
RCS file:/home/cvs/Repository/linux/include/asm-i386/posix_types.h,vretrieving revision 1.1.1.1
diff -u -u -r1.1.1.1posix_types.hasm-i386/posix_types.h 2001/02/13 13:49:18 renamed from asm-i386/posix_types.h 2000/09/04 16:50:33 1.1.1.1 +0
-0@@ -16,9 +16,9 @@ typedef unsigned short __kernel_ipc_pid_t; typedef unsigned short __kernel_uid_t; typedef unsigned short __kernel_gid_t;
Quoted 8 lines
asm-i386/posix_types.h 2001/02/13 13:49:18 line 21
Quoted 6 lines
asm-i386/posix_types.h 2001/02/13 13:49:18 renamed from asm-i386/posix_types.h 2000/09/04 16:50:33 1.1.1.1 +3
-3-typedef unsigned int __kernel_size_t; -typedef int __kernel_ssize_t; -typedef int __kernel_ptrdiff_t; +typedef unsigned long __kernel_size_t; +typedef long __kernel_ssize_t; +typedef long __kernel_ptrdiff_t;If it doesn't matter on i386 why bother?
It helps with printf %-formats to avoid some arch specific warnings.
Signature · 8 lines
Abramo Bagnara mailto:[email protected] Opera Unica Phone: +39.546.656023 Via Emilia Interna, 140 48014 Castel Bolognese (RA) - Italy ALSA project http://www.alsa-project.org It sounds good!
Quoted 3 lines · Pavel Machek
These are tiny cleanups you might like. sizes are "logically" long.
No. Sizes are not "logical". They are whatever you decide they are, ie it's purely a complier convention.
At least earlier, size_t was defined as "unsigned int" in user mode, and doing anything else would make gcc complain about clashes with its compiled-in __builtin_size_t that it uses for the builtin prototypes (ie if you had a declaration for "void *memcpy(void *dest, const void *src, size_t n);" and your size_t didn't match the gcc builtin_size_t, you'd get a "redefined with different arguments" warning or something).
Linus
Quoted 9 lines · Linus Torvalds
Quoted 3 lines · Pavel Machek
These are tiny cleanups you might like. sizes are "logically" long.
No. Sizes are not "logical". They are whatever you decide they are, ie it's purely a complier convention.
Not purely a compiler convention, but an ABI requirement. In particular, Linux GCC adheres to the ABI specified in the System V UNIX Intel386 (tm) Processor Supplement, and on page 6-66, in figure 6-70, the specification for stddef.h says that:
typedef int ptrdiff_t; typedef unsigned int size_t; typedef long wchar_t;
Quoted 6 lines
At least earlier,
size_twas defined as "unsigned int" in user mode, and doing anything else would make gcc complain about clashes with its compiled-in__builtin_size_tthat it uses for the builtin prototypes (ie if you had a declaration for "void *memcpy(void *dest, const void *src,size_tn);" and yoursize_tdidn't match the gccbuiltin_size_t, you'd get a "redefined with different arguments" warning or something).
While, I grant that this is one area the ABI could have been improved upon (alignment of floating point, and reservation of EBX as GOT pointers are other sore spots), it is the ABI of record. Yes, we could certainly choose a different ABI for Linux, but it is probably too late for that in the case of the x86.
Signature · 4 lines
Michael Meissner, Red Hat, Inc. (GCC group) PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: [email protected] phone: +1 978-486-9304 Non-work: [email protected] fax: +1 978-692-4482