Re: nios2: is the ptrace ABI correct?
On 2015/3/10 10:54 AM, Ley Foon Tan wrote:
> On Tue, Mar 10, 2015 at 1:05 AM, Ezequiel Garcia
> wrote:
>>
>>
>> On 03/09/2015 02:02 PM, Chung-Lin Tang wrote:
>>> On 2015/3/10 12:54 AM, Chung-Lin Tang wrote:
>>>> It appears that some of the ways nios2 has organized the
>>>> ucontext/pt_regs/etc. are remnants of the pre-generic code, some
>>>> basically because the port was based off m68k.
>>>>
>>>> I've re-organized the headers a bit: nios2/include/asm/ucontext.h is
>>>> deleted, and re-definition of struct sigcontext now allows use of
>>>> uapi/asm-generic/ucontext.h directly. Note that the reorg, despite
>>>> effectively renaming some fields, is still binary compatible. I'll
>>>> probably update the corresponding glibc definitions later.
>>>>
>>>> struct pt_regs is now not exported, and all exported register sets are
>>>> now supposed to follow the 49 register set defined as in GDB now.
>>>>
>>>> Tobias, Ley Foon, how do you think this looks?
>>>
>>> Sorry, accidentally attached unrelated GCC patch instead, this one's the
>>> correct one.
>>>
>>
>> Looks good. I'm wondering if...
>>
>> +/* User structures for general purpose registers. */
>> +struct user_pt_regs {
>> + __u32 regs[49];
>> };
>>
>> Can we expose the registers explicitly here? Like this:
>>
>> struct user_pt_regs {
>> __u32 r0;
>> __u32 r1;
>> ...
>> __u32 sp;
>> __u32 gp;
>> __u32 estatus;
>> };
>>
>> It looks self-documenting and thus easier to use.
>
> Hi Chung-Lin,
>
> Your patch look good to me.
> Do you have any problem to change the struct user_pt_regs based on
> Ezequiel's suggestion?
Well, exposing the register names like that sort of defeats the purpose of
the PTR_* defines.
Judging from the overall trend of style in arch/*/include/uapi/asm/ptrace.h
across ports, I would prefer to stay with the array field.
Thanks,
Chung-Lin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: nios2: is the ptrace ABI correct?
On 2015/3/10 10:54 AM, Ley Foon Tan wrote:
On Tue, Mar 10, 2015 at 1:05 AM, Ezequiel Garcia
ezequ...@vanguardiasur.com.ar wrote:
On 03/09/2015 02:02 PM, Chung-Lin Tang wrote:
On 2015/3/10 12:54 AM, Chung-Lin Tang wrote:
It appears that some of the ways nios2 has organized the
ucontext/pt_regs/etc. are remnants of the pre-generic code, some
basically because the port was based off m68k.
I've re-organized the headers a bit: nios2/include/asm/ucontext.h is
deleted, and re-definition of struct sigcontext now allows use of
uapi/asm-generic/ucontext.h directly. Note that the reorg, despite
effectively renaming some fields, is still binary compatible. I'll
probably update the corresponding glibc definitions later.
struct pt_regs is now not exported, and all exported register sets are
now supposed to follow the 49 register set defined as in GDB now.
Tobias, Ley Foon, how do you think this looks?
Sorry, accidentally attached unrelated GCC patch instead, this one's the
correct one.
Looks good. I'm wondering if...
+/* User structures for general purpose registers. */
+struct user_pt_regs {
+ __u32 regs[49];
};
Can we expose the registers explicitly here? Like this:
struct user_pt_regs {
__u32 r0;
__u32 r1;
...
__u32 sp;
__u32 gp;
__u32 estatus;
};
It looks self-documenting and thus easier to use.
Hi Chung-Lin,
Your patch look good to me.
Do you have any problem to change the struct user_pt_regs based on
Ezequiel's suggestion?
Well, exposing the register names like that sort of defeats the purpose of
the PTR_* defines.
Judging from the overall trend of style in arch/*/include/uapi/asm/ptrace.h
across ports, I would prefer to stay with the array field.
Thanks,
Chung-Lin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: nios2: is the ptrace ABI correct?
On 2015/3/10 12:54 AM, Chung-Lin Tang wrote:
> It appears that some of the ways nios2 has organized the
> ucontext/pt_regs/etc. are remnants of the pre-generic code, some
> basically because the port was based off m68k.
>
> I've re-organized the headers a bit: nios2/include/asm/ucontext.h is
> deleted, and re-definition of struct sigcontext now allows use of
> uapi/asm-generic/ucontext.h directly. Note that the reorg, despite
> effectively renaming some fields, is still binary compatible. I'll
> probably update the corresponding glibc definitions later.
>
> struct pt_regs is now not exported, and all exported register sets are
> now supposed to follow the 49 register set defined as in GDB now.
>
> Tobias, Ley Foon, how do you think this looks?
Sorry, accidentally attached unrelated GCC patch instead, this one's the
correct one.
Chung-Lin
diff --git a/arch/nios2/include/asm/ptrace.h b/arch/nios2/include/asm/ptrace.h
index 20fb1cf..6424621 100644
--- a/arch/nios2/include/asm/ptrace.h
+++ b/arch/nios2/include/asm/ptrace.h
@@ -15,7 +15,54 @@
#include
+/* This struct defines the way the registers are stored on the
+ stack during a system call. */
+
#ifndef __ASSEMBLY__
+struct pt_regs {
+ unsigned long r8; /* r8-r15 Caller-saved GP registers */
+ unsigned long r9;
+ unsigned long r10;
+ unsigned long r11;
+ unsigned long r12;
+ unsigned long r13;
+ unsigned long r14;
+ unsigned long r15;
+ unsigned long r1; /* Assembler temporary */
+ unsigned long r2; /* Retval LS 32bits */
+ unsigned long r3; /* Retval MS 32bits */
+ unsigned long r4; /* r4-r7 Register arguments */
+ unsigned long r5;
+ unsigned long r6;
+ unsigned long r7;
+ unsigned long orig_r2; /* Copy of r2 ?? */
+ unsigned long ra; /* Return address */
+ unsigned long fp; /* Frame pointer */
+ unsigned long sp; /* Stack pointer */
+ unsigned long gp; /* Global pointer */
+ unsigned long estatus;
+ unsigned long ea; /* Exception return address (pc) */
+ unsigned long orig_r7;
+};
+
+/*
+ * This is the extended stack used by signal handlers and the context
+ * switcher: it's pushed after the normal "struct pt_regs".
+ */
+struct switch_stack {
+ unsigned long r16; /* r16-r23 Callee-saved GP registers */
+ unsigned long r17;
+ unsigned long r18;
+ unsigned long r19;
+ unsigned long r20;
+ unsigned long r21;
+ unsigned long r22;
+ unsigned long r23;
+ unsigned long fp;
+ unsigned long gp;
+ unsigned long ra;
+};
+
#define user_mode(regs)(((regs)->estatus & ESTATUS_EU))
#define instruction_pointer(regs) ((regs)->ra)
diff --git a/arch/nios2/include/asm/ucontext.h
b/arch/nios2/include/asm/ucontext.h
deleted file mode 100644
index 2c87614..000
--- a/arch/nios2/include/asm/ucontext.h
+++ /dev/null
@@ -1,32 +0,0 @@
-/*
- * Copyright (C) 2010 Tobias Klauser
- * Copyright (C) 2004 Microtronix Datacom Ltd
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file "COPYING" in the main directory of this archive
- * for more details.
- */
-
-#ifndef _ASM_NIOS2_UCONTEXT_H
-#define _ASM_NIOS2_UCONTEXT_H
-
-typedef int greg_t;
-#define NGREG 32
-typedef greg_t gregset_t[NGREG];
-
-struct mcontext {
- int version;
- gregset_t gregs;
-};
-
-#define MCONTEXT_VERSION 2
-
-struct ucontext {
- unsigned long uc_flags;
- struct ucontext *uc_link;
- stack_t uc_stack;
- struct mcontext uc_mcontext;
- sigset_t uc_sigmask; /* mask last for extensibility */
-};
-
-#endif
diff --git a/arch/nios2/include/uapi/asm/Kbuild
b/arch/nios2/include/uapi/asm/Kbuild
index 4f07ca3f8..37613119 100644
--- a/arch/nios2/include/uapi/asm/Kbuild
+++ b/arch/nios2/include/uapi/asm/Kbuild
@@ -2,3 +2,5 @@ include include/uapi/asm-generic/Kbuild.asm
header-y += elf.h
header-y += ucontext.h
+
+generic-y += ucontext.h
diff --git a/arch/nios2/include/uapi/asm/elf.h
b/arch/nios2/include/uapi/asm/elf.h
index a5b91ae..6f06d3b 100644
--- a/arch/nios2/include/uapi/asm/elf.h
+++ b/arch/nios2/include/uapi/asm/elf.h
@@ -50,9 +50,7 @@
typedef unsigned long elf_greg_t;
-#define ELF_NGREG \
- ((sizeof(struct pt_regs) + sizeof(struct switch_stack)) / \
- sizeof(elf_greg_t))
+#define ELF_NGREG 49
typedef elf_greg_t elf_gregset_t[ELF_NGREG];
typedef unsigned long elf_fpregset_t;
diff --git a/arch/nios2/include/uapi/asm/ptrace.h
b/arch/nios2/include/uapi/asm/ptrace.h
index e83a7c9..71a3305 100644
--- a/arch/nios2/include/uapi/asm/ptrace.h
+++ b/arch/nios2/include/uapi/asm/ptrace.h
@@ -67,53 +67,9 @@
#define NUM_PTRACE_REG (PTR_TLBMISC + 1)
-
Re: nios2: is the ptrace ABI correct?
On 2015/2/27 07:19 PM, Ezequiel Garcia wrote:
> Right now, my biggest problem is how to remove the pt_regs from being
> exported to userspace, without breaking things. The struct is defined
> and used in a few UAPI headers:
>
> arch/nios2/include/uapi/asm/ptrace.h
> arch/nios2/include/uapi/asm/sigcontext.h
> arch/nios2/include/uapi/asm/elf.h
>
> For ucontext, we would need to remove
> arch/nios2/include/uapi/asm/sigcontext.h and avoid using
> asm-generic/ucontext.h.
>
> For ptrace, we could move pt_regs from the UAPI header to some internal
> header. That way userspace is not exposed the wrong struct.
>
> For the elf coredump, I have no idea yet :)
It appears that some of the ways nios2 has organized the
ucontext/pt_regs/etc. are remnants of the pre-generic code, some
basically because the port was based off m68k.
I've re-organized the headers a bit: nios2/include/asm/ucontext.h is
deleted, and re-definition of struct sigcontext now allows use of
uapi/asm-generic/ucontext.h directly. Note that the reorg, despite
effectively renaming some fields, is still binary compatible. I'll
probably update the corresponding glibc definitions later.
struct pt_regs is now not exported, and all exported register sets are
now supposed to follow the 49 register set defined as in GDB now.
Tobias, Ley Foon, how do you think this looks?
Thanks,
Chung-Lin
Index: gcc/config/nios2/nios2-protos.h
===
--- gcc/config/nios2/nios2-protos.h (revision 446123)
+++ gcc/config/nios2/nios2-protos.h (working copy)
@@ -32,7 +32,7 @@ extern void nios2_function_profiler (FILE *, int);
#ifdef RTX_CODE
extern bool nios2_emit_move_sequence (rtx *, enum machine_mode);
extern void nios2_emit_expensive_div (rtx *, enum machine_mode);
-extern void nios2_adjust_call_address (rtx *);
+extern void nios2_adjust_call_address (rtx *, rtx);
extern rtx nios2_get_return_address (int);
extern void nios2_set_return_address (rtx, rtx);
Index: gcc/config/nios2/nios2.c
===
--- gcc/config/nios2/nios2.c(revision 446123)
+++ gcc/config/nios2/nios2.c(working copy)
@@ -1511,12 +1511,12 @@ nios2_unspec_offset (rtx loc, int unspec)
/* Generate GOT pointer based address with large offset. */
static rtx
-nios2_large_got_address (rtx offset)
+nios2_large_got_address (rtx offset, rtx tmp)
{
- rtx addr = gen_reg_rtx (Pmode);
- emit_insn (gen_add3_insn (addr, pic_offset_table_rtx,
- force_reg (Pmode, offset)));
- return addr;
+ if (!tmp)
+tmp = gen_reg_rtx (Pmode);
+ emit_move_insn (tmp, offset);
+ return gen_rtx_PLUS (Pmode, tmp, pic_offset_table_rtx);
}
/* Generate a GOT pointer based address. */
@@ -1527,7 +1527,7 @@ nios2_got_address (rtx loc, int unspec)
crtl->uses_pic_offset_table = 1;
if (nios2_large_offset_p (unspec))
-return nios2_large_got_address (offset);
+return force_reg (Pmode, nios2_large_got_address (offset, NULL_RTX));
return gen_rtx_PLUS (Pmode, pic_offset_table_rtx, offset);
}
@@ -2080,13 +2080,17 @@ nios2_load_pic_register (void)
/* Generate a PIC address as a MEM rtx. */
static rtx
-nios2_load_pic_address (rtx sym, int unspec)
+nios2_load_pic_address (rtx sym, int unspec, rtx tmp)
{
if (flag_pic == 2
&& GET_CODE (sym) == SYMBOL_REF
&& nios2_symbol_binds_local_p (sym))
/* Under -fPIC, generate a GOTOFF address for local symbols. */
-return nios2_got_address (sym, UNSPEC_PIC_GOTOFF_SYM);
+{
+ rtx offset = nios2_unspec_offset (sym, UNSPEC_PIC_GOTOFF_SYM);
+ crtl->uses_pic_offset_table = 1;
+ return nios2_large_got_address (offset, tmp);
+}
return gen_const_mem (Pmode, nios2_got_address (sym, unspec));
}
@@ -2122,7 +2126,7 @@ nios2_legitimize_constant_address (rtx addr)
if (nios2_tls_symbol_p (base))
base = nios2_legitimize_tls_address (base);
else if (flag_pic)
-base = nios2_load_pic_address (base, UNSPEC_PIC_SYM);
+base = nios2_load_pic_address (base, UNSPEC_PIC_SYM, NULL_RTX);
else
return addr;
@@ -2266,18 +2270,24 @@ nios2_emit_move_sequence (rtx *operands, enum mach
/* The function with address *ADDR is being called. If the address
needs to be loaded from the GOT, emit the instruction to do so and
- update *ADDR to point to the rtx for the loaded value. */
+ update *ADDR to point to the rtx for the loaded value.
+ If REG != NULL_RTX, it is used as the target/scratch register in the
+ GOT address calculation. */
void
-nios2_adjust_call_address (rtx *call_op)
+nios2_adjust_call_address (rtx *call_op, rtx reg)
{
- rtx addr;
- gcc_assert (MEM_P (*call_op));
- addr = XEXP (*call_op, 0);
+ if (MEM_P (*call_op))
+call_op = (*call_op, 0);
+
+ rtx addr = *call_op;
if (flag_pic && CONSTANT_P (addr))
{
- rtx reg = gen_reg_rtx (Pmode);
- emit_move_insn (reg, nios2_load_pic_address (addr,
Re: nios2: is the ptrace ABI correct?
On 2015/3/10 12:54 AM, Chung-Lin Tang wrote:
It appears that some of the ways nios2 has organized the
ucontext/pt_regs/etc. are remnants of the pre-generic code, some
basically because the port was based off m68k.
I've re-organized the headers a bit: nios2/include/asm/ucontext.h is
deleted, and re-definition of struct sigcontext now allows use of
uapi/asm-generic/ucontext.h directly. Note that the reorg, despite
effectively renaming some fields, is still binary compatible. I'll
probably update the corresponding glibc definitions later.
struct pt_regs is now not exported, and all exported register sets are
now supposed to follow the 49 register set defined as in GDB now.
Tobias, Ley Foon, how do you think this looks?
Sorry, accidentally attached unrelated GCC patch instead, this one's the
correct one.
Chung-Lin
diff --git a/arch/nios2/include/asm/ptrace.h b/arch/nios2/include/asm/ptrace.h
index 20fb1cf..6424621 100644
--- a/arch/nios2/include/asm/ptrace.h
+++ b/arch/nios2/include/asm/ptrace.h
@@ -15,7 +15,54 @@
#include uapi/asm/ptrace.h
+/* This struct defines the way the registers are stored on the
+ stack during a system call. */
+
#ifndef __ASSEMBLY__
+struct pt_regs {
+ unsigned long r8; /* r8-r15 Caller-saved GP registers */
+ unsigned long r9;
+ unsigned long r10;
+ unsigned long r11;
+ unsigned long r12;
+ unsigned long r13;
+ unsigned long r14;
+ unsigned long r15;
+ unsigned long r1; /* Assembler temporary */
+ unsigned long r2; /* Retval LS 32bits */
+ unsigned long r3; /* Retval MS 32bits */
+ unsigned long r4; /* r4-r7 Register arguments */
+ unsigned long r5;
+ unsigned long r6;
+ unsigned long r7;
+ unsigned long orig_r2; /* Copy of r2 ?? */
+ unsigned long ra; /* Return address */
+ unsigned long fp; /* Frame pointer */
+ unsigned long sp; /* Stack pointer */
+ unsigned long gp; /* Global pointer */
+ unsigned long estatus;
+ unsigned long ea; /* Exception return address (pc) */
+ unsigned long orig_r7;
+};
+
+/*
+ * This is the extended stack used by signal handlers and the context
+ * switcher: it's pushed after the normal struct pt_regs.
+ */
+struct switch_stack {
+ unsigned long r16; /* r16-r23 Callee-saved GP registers */
+ unsigned long r17;
+ unsigned long r18;
+ unsigned long r19;
+ unsigned long r20;
+ unsigned long r21;
+ unsigned long r22;
+ unsigned long r23;
+ unsigned long fp;
+ unsigned long gp;
+ unsigned long ra;
+};
+
#define user_mode(regs)(((regs)-estatus ESTATUS_EU))
#define instruction_pointer(regs) ((regs)-ra)
diff --git a/arch/nios2/include/asm/ucontext.h
b/arch/nios2/include/asm/ucontext.h
deleted file mode 100644
index 2c87614..000
--- a/arch/nios2/include/asm/ucontext.h
+++ /dev/null
@@ -1,32 +0,0 @@
-/*
- * Copyright (C) 2010 Tobias Klauser tklau...@distanz.ch
- * Copyright (C) 2004 Microtronix Datacom Ltd
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file COPYING in the main directory of this archive
- * for more details.
- */
-
-#ifndef _ASM_NIOS2_UCONTEXT_H
-#define _ASM_NIOS2_UCONTEXT_H
-
-typedef int greg_t;
-#define NGREG 32
-typedef greg_t gregset_t[NGREG];
-
-struct mcontext {
- int version;
- gregset_t gregs;
-};
-
-#define MCONTEXT_VERSION 2
-
-struct ucontext {
- unsigned long uc_flags;
- struct ucontext *uc_link;
- stack_t uc_stack;
- struct mcontext uc_mcontext;
- sigset_t uc_sigmask; /* mask last for extensibility */
-};
-
-#endif
diff --git a/arch/nios2/include/uapi/asm/Kbuild
b/arch/nios2/include/uapi/asm/Kbuild
index 4f07ca3f8..37613119 100644
--- a/arch/nios2/include/uapi/asm/Kbuild
+++ b/arch/nios2/include/uapi/asm/Kbuild
@@ -2,3 +2,5 @@ include include/uapi/asm-generic/Kbuild.asm
header-y += elf.h
header-y += ucontext.h
+
+generic-y += ucontext.h
diff --git a/arch/nios2/include/uapi/asm/elf.h
b/arch/nios2/include/uapi/asm/elf.h
index a5b91ae..6f06d3b 100644
--- a/arch/nios2/include/uapi/asm/elf.h
+++ b/arch/nios2/include/uapi/asm/elf.h
@@ -50,9 +50,7 @@
typedef unsigned long elf_greg_t;
-#define ELF_NGREG \
- ((sizeof(struct pt_regs) + sizeof(struct switch_stack)) / \
- sizeof(elf_greg_t))
+#define ELF_NGREG 49
typedef elf_greg_t elf_gregset_t[ELF_NGREG];
typedef unsigned long elf_fpregset_t;
diff --git a/arch/nios2/include/uapi/asm/ptrace.h
b/arch/nios2/include/uapi/asm/ptrace.h
index e83a7c9..71a3305 100644
--- a/arch/nios2/include/uapi/asm/ptrace.h
+++ b/arch/nios2/include/uapi/asm/ptrace.h
@@ -67,53 +67,9 @@
#define NUM_PTRACE_REG (PTR_TLBMISC + 1)
-/* this struct defines the way the registers are stored
Re: nios2: is the ptrace ABI correct?
On 2015/2/27 07:19 PM, Ezequiel Garcia wrote:
Right now, my biggest problem is how to remove the pt_regs from being
exported to userspace, without breaking things. The struct is defined
and used in a few UAPI headers:
arch/nios2/include/uapi/asm/ptrace.h
arch/nios2/include/uapi/asm/sigcontext.h
arch/nios2/include/uapi/asm/elf.h
For ucontext, we would need to remove
arch/nios2/include/uapi/asm/sigcontext.h and avoid using
asm-generic/ucontext.h.
For ptrace, we could move pt_regs from the UAPI header to some internal
header. That way userspace is not exposed the wrong struct.
For the elf coredump, I have no idea yet :)
It appears that some of the ways nios2 has organized the
ucontext/pt_regs/etc. are remnants of the pre-generic code, some
basically because the port was based off m68k.
I've re-organized the headers a bit: nios2/include/asm/ucontext.h is
deleted, and re-definition of struct sigcontext now allows use of
uapi/asm-generic/ucontext.h directly. Note that the reorg, despite
effectively renaming some fields, is still binary compatible. I'll
probably update the corresponding glibc definitions later.
struct pt_regs is now not exported, and all exported register sets are
now supposed to follow the 49 register set defined as in GDB now.
Tobias, Ley Foon, how do you think this looks?
Thanks,
Chung-Lin
Index: gcc/config/nios2/nios2-protos.h
===
--- gcc/config/nios2/nios2-protos.h (revision 446123)
+++ gcc/config/nios2/nios2-protos.h (working copy)
@@ -32,7 +32,7 @@ extern void nios2_function_profiler (FILE *, int);
#ifdef RTX_CODE
extern bool nios2_emit_move_sequence (rtx *, enum machine_mode);
extern void nios2_emit_expensive_div (rtx *, enum machine_mode);
-extern void nios2_adjust_call_address (rtx *);
+extern void nios2_adjust_call_address (rtx *, rtx);
extern rtx nios2_get_return_address (int);
extern void nios2_set_return_address (rtx, rtx);
Index: gcc/config/nios2/nios2.c
===
--- gcc/config/nios2/nios2.c(revision 446123)
+++ gcc/config/nios2/nios2.c(working copy)
@@ -1511,12 +1511,12 @@ nios2_unspec_offset (rtx loc, int unspec)
/* Generate GOT pointer based address with large offset. */
static rtx
-nios2_large_got_address (rtx offset)
+nios2_large_got_address (rtx offset, rtx tmp)
{
- rtx addr = gen_reg_rtx (Pmode);
- emit_insn (gen_add3_insn (addr, pic_offset_table_rtx,
- force_reg (Pmode, offset)));
- return addr;
+ if (!tmp)
+tmp = gen_reg_rtx (Pmode);
+ emit_move_insn (tmp, offset);
+ return gen_rtx_PLUS (Pmode, tmp, pic_offset_table_rtx);
}
/* Generate a GOT pointer based address. */
@@ -1527,7 +1527,7 @@ nios2_got_address (rtx loc, int unspec)
crtl-uses_pic_offset_table = 1;
if (nios2_large_offset_p (unspec))
-return nios2_large_got_address (offset);
+return force_reg (Pmode, nios2_large_got_address (offset, NULL_RTX));
return gen_rtx_PLUS (Pmode, pic_offset_table_rtx, offset);
}
@@ -2080,13 +2080,17 @@ nios2_load_pic_register (void)
/* Generate a PIC address as a MEM rtx. */
static rtx
-nios2_load_pic_address (rtx sym, int unspec)
+nios2_load_pic_address (rtx sym, int unspec, rtx tmp)
{
if (flag_pic == 2
GET_CODE (sym) == SYMBOL_REF
nios2_symbol_binds_local_p (sym))
/* Under -fPIC, generate a GOTOFF address for local symbols. */
-return nios2_got_address (sym, UNSPEC_PIC_GOTOFF_SYM);
+{
+ rtx offset = nios2_unspec_offset (sym, UNSPEC_PIC_GOTOFF_SYM);
+ crtl-uses_pic_offset_table = 1;
+ return nios2_large_got_address (offset, tmp);
+}
return gen_const_mem (Pmode, nios2_got_address (sym, unspec));
}
@@ -2122,7 +2126,7 @@ nios2_legitimize_constant_address (rtx addr)
if (nios2_tls_symbol_p (base))
base = nios2_legitimize_tls_address (base);
else if (flag_pic)
-base = nios2_load_pic_address (base, UNSPEC_PIC_SYM);
+base = nios2_load_pic_address (base, UNSPEC_PIC_SYM, NULL_RTX);
else
return addr;
@@ -2266,18 +2270,24 @@ nios2_emit_move_sequence (rtx *operands, enum mach
/* The function with address *ADDR is being called. If the address
needs to be loaded from the GOT, emit the instruction to do so and
- update *ADDR to point to the rtx for the loaded value. */
+ update *ADDR to point to the rtx for the loaded value.
+ If REG != NULL_RTX, it is used as the target/scratch register in the
+ GOT address calculation. */
void
-nios2_adjust_call_address (rtx *call_op)
+nios2_adjust_call_address (rtx *call_op, rtx reg)
{
- rtx addr;
- gcc_assert (MEM_P (*call_op));
- addr = XEXP (*call_op, 0);
+ if (MEM_P (*call_op))
+call_op = XEXP (*call_op, 0);
+
+ rtx addr = *call_op;
if (flag_pic CONSTANT_P (addr))
{
- rtx reg = gen_reg_rtx (Pmode);
- emit_move_insn (reg, nios2_load_pic_address (addr, UNSPEC_PIC_CALL_SYM));
- XEXP
Re: nios2: is the ptrace ABI correct?
On 15/2/25 10:07 PM, Arnd Bergmann wrote:
> On Wednesday 25 February 2015 08:33:16 Ezequiel Garcia wrote:
>>
>> /me is more confused now
>>
>> In arch/nios2/include/asm/ucontext.h
>>
>> struct ucontext {
>> unsigned long uc_flags;
>> struct ucontext *uc_link;
>> stack_t uc_stack;
>> struct mcontext uc_mcontext;
>> sigset_t uc_sigmask;
>> };
>>
>> And in include/uapi/asm-generic/ucontext.h:
>>
>> struct ucontext {
>> unsigned long uc_flags;
>> struct ucontext *uc_link;
>> stack_t uc_stack;
>> struct sigcontext uc_mcontext;
>> sigset_t uc_sigmask;
>> };
>>
>> Which one is the one that userspace sees? And why does the kernel has
>> two different structures?
>
> Userspace sees the asm-generic header, which I assume is a bug
> in this case.
Yes, I believe nios2 doesn't not need this asm-generic/ucontext.h
header; OTOH it just isn't used; no real harm done, so easily fixed.
>> Given this oddities, I'm wondering how troublesome would be to just
>> re-do this and break the ptrace and signal ABI. For instance, just
>> pushing pt_regs in PTRACE_GETREGSET would make things much clearer.
>
> Could you change pt_regs to match the layout you have for PTRACE_GETREGSET
> instead? It seems much more intuitive.
There is a reason for this pt_regs arrangement: the nios2 syscall
interface uses r4-r9 for parameters, while the usual C conventions use
only r4-r7, placing r8-r9 at the start of pt_regs creates a natural
stack layout for entering C code after the asm shims in entry.S
>> I guess Linus would burn me for even suggesting to breaking users... but
>> do we have any users at all? This arch has just been mainlined. Altera's
>> out-of-tree is already ABI-incompatible with mainline so that's not an
>> issue.
>>
>> The only one using this ABI is gdb, which is easily fixed.
>
> You can change anything you like as long as nobody complains about
> regressions.
PTRACE_GET/SETREGSET is a new feature in nios2-linux that we're still
about to support in upstream GDB, so things could be fixed if needed,
but why can't you just use the [0...] ordering in userspace?
BTW, it's even that way in signal stacks as well; nios2 does not
use/export sigcontext inside struct ucontext. We just use a int[32]
array there.
Thanks,
Chung-Lin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: nios2: is the ptrace ABI correct?
On 15/2/25 10:07 PM, Arnd Bergmann wrote:
On Wednesday 25 February 2015 08:33:16 Ezequiel Garcia wrote:
/me is more confused now
In arch/nios2/include/asm/ucontext.h
struct ucontext {
unsigned long uc_flags;
struct ucontext *uc_link;
stack_t uc_stack;
struct mcontext uc_mcontext;
sigset_t uc_sigmask;
};
And in include/uapi/asm-generic/ucontext.h:
struct ucontext {
unsigned long uc_flags;
struct ucontext *uc_link;
stack_t uc_stack;
struct sigcontext uc_mcontext;
sigset_t uc_sigmask;
};
Which one is the one that userspace sees? And why does the kernel has
two different structures?
Userspace sees the asm-generic header, which I assume is a bug
in this case.
Yes, I believe nios2 doesn't not need this asm-generic/ucontext.h
header; OTOH it just isn't used; no real harm done, so easily fixed.
Given this oddities, I'm wondering how troublesome would be to just
re-do this and break the ptrace and signal ABI. For instance, just
pushing pt_regs in PTRACE_GETREGSET would make things much clearer.
Could you change pt_regs to match the layout you have for PTRACE_GETREGSET
instead? It seems much more intuitive.
There is a reason for this pt_regs arrangement: the nios2 syscall
interface uses r4-r9 for parameters, while the usual C conventions use
only r4-r7, placing r8-r9 at the start of pt_regs creates a natural
stack layout for entering C code after the asm shims in entry.S
I guess Linus would burn me for even suggesting to breaking users... but
do we have any users at all? This arch has just been mainlined. Altera's
out-of-tree is already ABI-incompatible with mainline so that's not an
issue.
The only one using this ABI is gdb, which is easily fixed.
You can change anything you like as long as nobody complains about
regressions.
PTRACE_GET/SETREGSET is a new feature in nios2-linux that we're still
about to support in upstream GDB, so things could be fixed if needed,
but why can't you just use the [0...] ordering in userspace?
BTW, it's even that way in signal stacks as well; nios2 does not
use/export sigcontext inside struct ucontext. We just use a int[32]
array there.
Thanks,
Chung-Lin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nios2: __kuser_sigtramp placement fix
On 2015/1/22 下午 04:43, Ley Foon Tan wrote: > On Thu, Jan 22, 2015 at 4:15 PM, Chung-Lin Tang > wrote: >> On 2015/1/22 03:54 PM, Ley Foon Tan wrote: >>> On Thu, Jan 22, 2015 at 3:14 PM, Chung-Lin Tang >>> wrote: >>>> The address of __kuser_sigtramp is wrong by one word, due to padding >>>> __kuser_cmpxchg to fully 64 bytes. The version word at the start of the >>>> page displaces __kuser_sigtramp to 0x1044, instead of the intended 0x1040. >>>> >>>> Fixed by counting the 64-byte frame from the start of the page instead >>>> of __kuser_cmpxchg. This shortens the __kuser_cmpxchg frame to 60-bytes, >>>> but that's likely enough. >>>> >>>> The zero-byte padding parts of the kuser_pad macro has been removed, due >>>> to the .if command refusing to behave properly when there are other >>>> .word directives in between. Probably a binutils gas bug. >>>> >>>> Thanks, >>>> Chung-Lin >>>> >>>> Cc: Ley Foon Tan >>>> Cc: Tobias Klauser >>>> Signed-off-by: Chung-Lin Tang >>>> >>>> diff --git a/arch/nios2/kernel/entry.S b/arch/nios2/kernel/entry.S >>>> index 0bdfd13..3224839 100644 >>>> --- a/arch/nios2/kernel/entry.S >>>> +++ b/arch/nios2/kernel/entry.S >>>> @@ -492,14 +492,7 @@ ENTRY(ret_from_kernel_thread) >>>> >>>> /* Filling pads with undefined instructions. */ >>>> .macro kuser_pad sym size >>>> - .if ((. - \sym) & 3) >>>> - .rept (4 - (. - \sym) & 3) >>>> - .byte 0 >>>> - .endr >>>> - .endif >>>> - .rept ((\size - (. - \sym)) / 4) >>>> - .word 0xdeadbeef >>>> - .endr >>>> + .fill ((\size - (. - \sym)) / 4), 4, 0xdeadbeef >>>> .endm >>>> >>>> .align 6 >>>> @@ -526,7 +519,10 @@ cmpxchg_stw: >>>> cmpxchg_ret: >>>> ret >>>> >>>> - kuser_pad __kuser_cmpxchg, 64 >>>> + /* The first 64-byte frame contains the version word, so note >>>> + that the first padding entry is based from the start of the >>>> kuser >>>> + page, instead of __kuser_cmpxchg. */ >>>> + kuser_pad __kuser_helper_start, 64 >>>> >>>> .globl __kuser_sigtramp >>>> __kuser_sigtramp: >>>> -- >>> Hi Chung-Lin >>> >>> I thought this is our original intention for it. >>> >>> First 4 bytes is the __kuser_version and each __kuser function will >>> have 64 bytes size. >>> >>> 0x1000 __kuser_helper_version >>> 0x1004 __kuser_cmpxchg >>> 0x1044 __kuser_sigtramp >>> >>> Any reason you can't use __kuser_sigtramp @ 0x1044? >> >> Well, that's okay as well, as the main place which sets this is the >> signal frame construction in arch/nios2/kernel/signal.c. The user space >> is mostly oblivious to the exact location. You'll need to update it >> that way if you prefer 0x1044, as it's currently set at 0x1040. >> >> I suggested 0x1040 because 64b frames aligned at 64b seemed more >> intuitive; __kuser_cmpxchg would be a special case. > > I think I will change to 0x1044 in arch/nios2/kernel/signal.c. I can > submit the fix. > Do you need to update toolchain for this change? No, the toolchain is not affected by this change. Thanks, Chung-Lin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nios2: __kuser_sigtramp placement fix
On 2015/1/22 03:54 PM, Ley Foon Tan wrote: > On Thu, Jan 22, 2015 at 3:14 PM, Chung-Lin Tang > wrote: >> The address of __kuser_sigtramp is wrong by one word, due to padding >> __kuser_cmpxchg to fully 64 bytes. The version word at the start of the >> page displaces __kuser_sigtramp to 0x1044, instead of the intended 0x1040. >> >> Fixed by counting the 64-byte frame from the start of the page instead >> of __kuser_cmpxchg. This shortens the __kuser_cmpxchg frame to 60-bytes, >> but that's likely enough. >> >> The zero-byte padding parts of the kuser_pad macro has been removed, due >> to the .if command refusing to behave properly when there are other >> .word directives in between. Probably a binutils gas bug. >> >> Thanks, >> Chung-Lin >> >> Cc: Ley Foon Tan >> Cc: Tobias Klauser >> Signed-off-by: Chung-Lin Tang >> >> diff --git a/arch/nios2/kernel/entry.S b/arch/nios2/kernel/entry.S >> index 0bdfd13..3224839 100644 >> --- a/arch/nios2/kernel/entry.S >> +++ b/arch/nios2/kernel/entry.S >> @@ -492,14 +492,7 @@ ENTRY(ret_from_kernel_thread) >> >> /* Filling pads with undefined instructions. */ >> .macro kuser_pad sym size >> - .if ((. - \sym) & 3) >> - .rept (4 - (. - \sym) & 3) >> - .byte 0 >> - .endr >> - .endif >> - .rept ((\size - (. - \sym)) / 4) >> - .word 0xdeadbeef >> - .endr >> + .fill ((\size - (. - \sym)) / 4), 4, 0xdeadbeef >> .endm >> >> .align 6 >> @@ -526,7 +519,10 @@ cmpxchg_stw: >> cmpxchg_ret: >> ret >> >> - kuser_pad __kuser_cmpxchg, 64 >> + /* The first 64-byte frame contains the version word, so note >> + that the first padding entry is based from the start of the kuser >> + page, instead of __kuser_cmpxchg. */ >> + kuser_pad __kuser_helper_start, 64 >> >> .globl __kuser_sigtramp >> __kuser_sigtramp: >> -- > Hi Chung-Lin > > I thought this is our original intention for it. > > First 4 bytes is the __kuser_version and each __kuser function will > have 64 bytes size. > > 0x1000 __kuser_helper_version > 0x1004 __kuser_cmpxchg > 0x1044 __kuser_sigtramp > > Any reason you can't use __kuser_sigtramp @ 0x1044? Well, that's okay as well, as the main place which sets this is the signal frame construction in arch/nios2/kernel/signal.c. The user space is mostly oblivious to the exact location. You'll need to update it that way if you prefer 0x1044, as it's currently set at 0x1040. I suggested 0x1040 because 64b frames aligned at 64b seemed more intuitive; __kuser_cmpxchg would be a special case. Chung-Lin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nios2: __kuser_sigtramp placement fix
On 2015/1/22 03:54 PM, Ley Foon Tan wrote: On Thu, Jan 22, 2015 at 3:14 PM, Chung-Lin Tang chunglin.t...@gmail.com wrote: The address of __kuser_sigtramp is wrong by one word, due to padding __kuser_cmpxchg to fully 64 bytes. The version word at the start of the page displaces __kuser_sigtramp to 0x1044, instead of the intended 0x1040. Fixed by counting the 64-byte frame from the start of the page instead of __kuser_cmpxchg. This shortens the __kuser_cmpxchg frame to 60-bytes, but that's likely enough. The zero-byte padding parts of the kuser_pad macro has been removed, due to the .if command refusing to behave properly when there are other .word directives in between. Probably a binutils gas bug. Thanks, Chung-Lin Cc: Ley Foon Tan lf...@altera.com Cc: Tobias Klauser tklau...@distanz.ch Signed-off-by: Chung-Lin Tang clt...@codesourcery.com diff --git a/arch/nios2/kernel/entry.S b/arch/nios2/kernel/entry.S index 0bdfd13..3224839 100644 --- a/arch/nios2/kernel/entry.S +++ b/arch/nios2/kernel/entry.S @@ -492,14 +492,7 @@ ENTRY(ret_from_kernel_thread) /* Filling pads with undefined instructions. */ .macro kuser_pad sym size - .if ((. - \sym) 3) - .rept (4 - (. - \sym) 3) - .byte 0 - .endr - .endif - .rept ((\size - (. - \sym)) / 4) - .word 0xdeadbeef - .endr + .fill ((\size - (. - \sym)) / 4), 4, 0xdeadbeef .endm .align 6 @@ -526,7 +519,10 @@ cmpxchg_stw: cmpxchg_ret: ret - kuser_pad __kuser_cmpxchg, 64 + /* The first 64-byte frame contains the version word, so note + that the first padding entry is based from the start of the kuser + page, instead of __kuser_cmpxchg. */ + kuser_pad __kuser_helper_start, 64 .globl __kuser_sigtramp __kuser_sigtramp: -- Hi Chung-Lin I thought this is our original intention for it. First 4 bytes is the __kuser_version and each __kuser function will have 64 bytes size. 0x1000 __kuser_helper_version 0x1004 __kuser_cmpxchg 0x1044 __kuser_sigtramp Any reason you can't use __kuser_sigtramp @ 0x1044? Well, that's okay as well, as the main place which sets this is the signal frame construction in arch/nios2/kernel/signal.c. The user space is mostly oblivious to the exact location. You'll need to update it that way if you prefer 0x1044, as it's currently set at 0x1040. I suggested 0x1040 because 64b frames aligned at 64b seemed more intuitive; __kuser_cmpxchg would be a special case. Chung-Lin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] nios2: __kuser_sigtramp placement fix
On 2015/1/22 下午 04:43, Ley Foon Tan wrote: On Thu, Jan 22, 2015 at 4:15 PM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2015/1/22 03:54 PM, Ley Foon Tan wrote: On Thu, Jan 22, 2015 at 3:14 PM, Chung-Lin Tang chunglin.t...@gmail.com wrote: The address of __kuser_sigtramp is wrong by one word, due to padding __kuser_cmpxchg to fully 64 bytes. The version word at the start of the page displaces __kuser_sigtramp to 0x1044, instead of the intended 0x1040. Fixed by counting the 64-byte frame from the start of the page instead of __kuser_cmpxchg. This shortens the __kuser_cmpxchg frame to 60-bytes, but that's likely enough. The zero-byte padding parts of the kuser_pad macro has been removed, due to the .if command refusing to behave properly when there are other .word directives in between. Probably a binutils gas bug. Thanks, Chung-Lin Cc: Ley Foon Tan lf...@altera.com Cc: Tobias Klauser tklau...@distanz.ch Signed-off-by: Chung-Lin Tang clt...@codesourcery.com diff --git a/arch/nios2/kernel/entry.S b/arch/nios2/kernel/entry.S index 0bdfd13..3224839 100644 --- a/arch/nios2/kernel/entry.S +++ b/arch/nios2/kernel/entry.S @@ -492,14 +492,7 @@ ENTRY(ret_from_kernel_thread) /* Filling pads with undefined instructions. */ .macro kuser_pad sym size - .if ((. - \sym) 3) - .rept (4 - (. - \sym) 3) - .byte 0 - .endr - .endif - .rept ((\size - (. - \sym)) / 4) - .word 0xdeadbeef - .endr + .fill ((\size - (. - \sym)) / 4), 4, 0xdeadbeef .endm .align 6 @@ -526,7 +519,10 @@ cmpxchg_stw: cmpxchg_ret: ret - kuser_pad __kuser_cmpxchg, 64 + /* The first 64-byte frame contains the version word, so note + that the first padding entry is based from the start of the kuser + page, instead of __kuser_cmpxchg. */ + kuser_pad __kuser_helper_start, 64 .globl __kuser_sigtramp __kuser_sigtramp: -- Hi Chung-Lin I thought this is our original intention for it. First 4 bytes is the __kuser_version and each __kuser function will have 64 bytes size. 0x1000 __kuser_helper_version 0x1004 __kuser_cmpxchg 0x1044 __kuser_sigtramp Any reason you can't use __kuser_sigtramp @ 0x1044? Well, that's okay as well, as the main place which sets this is the signal frame construction in arch/nios2/kernel/signal.c. The user space is mostly oblivious to the exact location. You'll need to update it that way if you prefer 0x1044, as it's currently set at 0x1040. I suggested 0x1040 because 64b frames aligned at 64b seemed more intuitive; __kuser_cmpxchg would be a special case. I think I will change to 0x1044 in arch/nios2/kernel/signal.c. I can submit the fix. Do you need to update toolchain for this change? No, the toolchain is not affected by this change. Thanks, Chung-Lin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] nios2: __kuser_sigtramp placement fix
The address of __kuser_sigtramp is wrong by one word, due to padding __kuser_cmpxchg to fully 64 bytes. The version word at the start of the page displaces __kuser_sigtramp to 0x1044, instead of the intended 0x1040. Fixed by counting the 64-byte frame from the start of the page instead of __kuser_cmpxchg. This shortens the __kuser_cmpxchg frame to 60-bytes, but that's likely enough. The zero-byte padding parts of the kuser_pad macro has been removed, due to the .if command refusing to behave properly when there are other .word directives in between. Probably a binutils gas bug. Thanks, Chung-Lin Cc: Ley Foon Tan Cc: Tobias Klauser Signed-off-by: Chung-Lin Tang diff --git a/arch/nios2/kernel/entry.S b/arch/nios2/kernel/entry.S index 0bdfd13..3224839 100644 --- a/arch/nios2/kernel/entry.S +++ b/arch/nios2/kernel/entry.S @@ -492,14 +492,7 @@ ENTRY(ret_from_kernel_thread) /* Filling pads with undefined instructions. */ .macro kuser_pad sym size - .if ((. - \sym) & 3) - .rept (4 - (. - \sym) & 3) - .byte 0 - .endr - .endif - .rept ((\size - (. - \sym)) / 4) - .word 0xdeadbeef - .endr + .fill ((\size - (. - \sym)) / 4), 4, 0xdeadbeef .endm .align 6 @@ -526,7 +519,10 @@ cmpxchg_stw: cmpxchg_ret: ret - kuser_pad __kuser_cmpxchg, 64 + /* The first 64-byte frame contains the version word, so note + that the first padding entry is based from the start of the kuser + page, instead of __kuser_cmpxchg. */ + kuser_pad __kuser_helper_start, 64 .globl __kuser_sigtramp __kuser_sigtramp: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] nios2: __kuser_sigtramp placement fix
The address of __kuser_sigtramp is wrong by one word, due to padding __kuser_cmpxchg to fully 64 bytes. The version word at the start of the page displaces __kuser_sigtramp to 0x1044, instead of the intended 0x1040. Fixed by counting the 64-byte frame from the start of the page instead of __kuser_cmpxchg. This shortens the __kuser_cmpxchg frame to 60-bytes, but that's likely enough. The zero-byte padding parts of the kuser_pad macro has been removed, due to the .if command refusing to behave properly when there are other .word directives in between. Probably a binutils gas bug. Thanks, Chung-Lin Cc: Ley Foon Tan lf...@altera.com Cc: Tobias Klauser tklau...@distanz.ch Signed-off-by: Chung-Lin Tang clt...@codesourcery.com diff --git a/arch/nios2/kernel/entry.S b/arch/nios2/kernel/entry.S index 0bdfd13..3224839 100644 --- a/arch/nios2/kernel/entry.S +++ b/arch/nios2/kernel/entry.S @@ -492,14 +492,7 @@ ENTRY(ret_from_kernel_thread) /* Filling pads with undefined instructions. */ .macro kuser_pad sym size - .if ((. - \sym) 3) - .rept (4 - (. - \sym) 3) - .byte 0 - .endr - .endif - .rept ((\size - (. - \sym)) / 4) - .word 0xdeadbeef - .endr + .fill ((\size - (. - \sym)) / 4), 4, 0xdeadbeef .endm .align 6 @@ -526,7 +519,10 @@ cmpxchg_stw: cmpxchg_ret: ret - kuser_pad __kuser_cmpxchg, 64 + /* The first 64-byte frame contains the version word, so note + that the first padding entry is based from the start of the kuser + page, instead of __kuser_cmpxchg. */ + kuser_pad __kuser_helper_start, 64 .globl __kuser_sigtramp __kuser_sigtramp: -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 25/29] nios2: Module support
On 14/9/10 5:25 AM, valdis.kletni...@vt.edu wrote: > On Mon, 08 Sep 2014 17:22:36 +0800, Ley Foon Tan said: >> This patch adds support for loadable modules. >> >> Signed-off-by: Ley Foon Tan > >> +/* >> + * Modules should NOT be allocated with kmalloc for (obvious) reasons. >> + * But we do it for now to avoid relocation issues. CALL26/PCREL26 cannot >> reach >> + * from 0x8000 (vmalloc area) to 0xc (kernel) (kmalloc returns >> + * addresses in 0xc000) >> + */ > > That's a nice scary comment to see. :) > > What's the long-term plan here? > We would probably need to add the ability to add trampolines in some way, though this of course impairs a little performance. Or if the default region of vmalloc can be configured to use the same 256MB region as the kernel. I wonder how MIPS (which has similar same-region call/jump instructions) deals with this? Chung-Lin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 25/29] nios2: Module support
On 14/9/10 5:25 AM, valdis.kletni...@vt.edu wrote: On Mon, 08 Sep 2014 17:22:36 +0800, Ley Foon Tan said: This patch adds support for loadable modules. Signed-off-by: Ley Foon Tan lf...@altera.com +/* + * Modules should NOT be allocated with kmalloc for (obvious) reasons. + * But we do it for now to avoid relocation issues. CALL26/PCREL26 cannot reach + * from 0x8000 (vmalloc area) to 0xc (kernel) (kmalloc returns + * addresses in 0xc000) + */ That's a nice scary comment to see. :) What's the long-term plan here? We would probably need to add the ability to add trampolines in some way, though this of course impairs a little performance. Or if the default region of vmalloc can be configured to use the same 256MB region as the kernel. I wonder how MIPS (which has similar same-region call/jump instructions) deals with this? Chung-Lin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 22/29] nios2: Miscellaneous header files
Hi Arnd, Considering two other kernel interface issues that appeared earlier in the context of nios2 glibc/kernel upstreaming: (1) The 64-bit time_t/timespec issue. (2) Dropping renameat by default in favor of renameat2 What's the decision for these? Are they delayed to the next release? Thanks, Chung-Lin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 22/29] nios2: Miscellaneous header files
Hi Arnd, Considering two other kernel interface issues that appeared earlier in the context of nios2 glibc/kernel upstreaming: (1) The 64-bit time_t/timespec issue. (2) Dropping renameat by default in favor of renameat2 What's the decision for these? Are they delayed to the next release? Thanks, Chung-Lin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 22/29] nios2: Miscellaneous header files
On 2014/7/15 06:22 PM, Arnd Bergmann wrote:
>> +
>> > +#ifndef _UAPI_ASM_NIOS2_STATFS_H
>> > +#define _UAPI_ASM_NIOS2_STATFS_H
>> > +
>> > +#define __statfs_word __s32
> Why this? Every other architecture except parisc uses the default __u32 here.
Because include/uapi/asm/statfs.h has this:
#ifndef __statfs_word
#if __BITS_PER_LONG == 64
#define __statfs_word __kernel_long_t
#else
#define __statfs_word __u32
#endif
#endif
...
struct statfs64 {
__statfs_word f_type;
__statfs_word f_bsize;
__u64 f_blocks;
__u64 f_bfree;
...
While the bits/statfs.h header in glibc has this:
struct statfs
{
__SWORD_TYPE f_type;
__SWORD_TYPE f_bsize;
__field64(__fsblkcnt_t, __fsblkcnt64_t, f_blocks);
...
struct statfs64
{
__SWORD_TYPE f_type;
__SWORD_TYPE f_bsize;
__fsblkcnt64_t f_blocks;
...
Where __SWORD_TYPE is always a signed integer (int or long int depending
on 32/64-bit word size). Hence we define the kernel __statfs_word to be
signed 32-bit to match.
Supposedly, tilepro should have a similar issue too, though I guess this
is quite obscure in practice. We so far haven't encountered any issues
on nios2 without this __s32 override either, it's just by observation.
>> > +#include
>> > +#include
>> > +
>> > +#ifdef CONFIG_NIOS2_CI_SWAB_SUPPORT
>> > +#ifdef __GNUC__
>> > +
>> > +#define __nios2_swab(x) \
>> > + __builtin_custom_ini(CONFIG_NIOS2_CI_SWAB_NO, (x))
>> > +
>> > +static inline __attribute__((const)) __u16 __arch_swab16(__u16 x)
>> > +{
>> > + return (__u16) __nios2_swab(((__u32) x) << 16);
>> > +}
> Is this actually better than ___constant_swab16()?
>
> Also, have you checked if you need to support old compiler versions that
> don't have __builtin_bswap16/32/64? With newer compilers you don't need
> to define any of these yourself.
>
> Arnd
This swap is configured/implemented using Nios II's custom instruction
facility; it is not part of the compiler supported Nios II core
instruction set. In fact, even the exact opcode allocated is not fixed.
So the custom swap will not be in a form usable by the compiler, and
hence no use of it during code generation (if it is, you might not even
need to use __builtin_swap*(), there's a optimization pass that
recognizes the shift+or-ing C code patterns)
Thanks,
Chung-Lin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 22/29] nios2: Miscellaneous header files
On 2014/7/15 06:22 PM, Arnd Bergmann wrote:
+
+#ifndef _UAPI_ASM_NIOS2_STATFS_H
+#define _UAPI_ASM_NIOS2_STATFS_H
+
+#define __statfs_word __s32
Why this? Every other architecture except parisc uses the default __u32 here.
Because include/uapi/asm/statfs.h has this:
#ifndef __statfs_word
#if __BITS_PER_LONG == 64
#define __statfs_word __kernel_long_t
#else
#define __statfs_word __u32
#endif
#endif
...
struct statfs64 {
__statfs_word f_type;
__statfs_word f_bsize;
__u64 f_blocks;
__u64 f_bfree;
...
While the bits/statfs.h header in glibc has this:
struct statfs
{
__SWORD_TYPE f_type;
__SWORD_TYPE f_bsize;
__field64(__fsblkcnt_t, __fsblkcnt64_t, f_blocks);
...
struct statfs64
{
__SWORD_TYPE f_type;
__SWORD_TYPE f_bsize;
__fsblkcnt64_t f_blocks;
...
Where __SWORD_TYPE is always a signed integer (int or long int depending
on 32/64-bit word size). Hence we define the kernel __statfs_word to be
signed 32-bit to match.
Supposedly, tilepro should have a similar issue too, though I guess this
is quite obscure in practice. We so far haven't encountered any issues
on nios2 without this __s32 override either, it's just by observation.
+#include linux/types.h
+#include asm-generic/swab.h
+
+#ifdef CONFIG_NIOS2_CI_SWAB_SUPPORT
+#ifdef __GNUC__
+
+#define __nios2_swab(x) \
+ __builtin_custom_ini(CONFIG_NIOS2_CI_SWAB_NO, (x))
+
+static inline __attribute__((const)) __u16 __arch_swab16(__u16 x)
+{
+ return (__u16) __nios2_swab(((__u32) x) 16);
+}
Is this actually better than ___constant_swab16()?
Also, have you checked if you need to support old compiler versions that
don't have __builtin_bswap16/32/64? With newer compilers you don't need
to define any of these yourself.
Arnd
This swap is configured/implemented using Nios II's custom instruction
facility; it is not part of the compiler supported Nios II core
instruction set. In fact, even the exact opcode allocated is not fixed.
So the custom swap will not be in a form usable by the compiler, and
hence no use of it during code generation (if it is, you might not even
need to use __builtin_swap*(), there's a optimization pass that
recognizes the shift+or-ing C code patterns)
Thanks,
Chung-Lin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
On 2014/5/15 07:08 PM, Arnd Bergmann wrote: > On Wednesday 14 May 2014 14:33:18 John Stultz wrote: >> On Tue, May 13, 2014 at 12:32 PM, Arnd Bergmann wrote: >>> On Tuesday 13 May 2014 20:24:59 Geert Uytterhoeven wrote: On Tue, May 13, 2014 at 8:10 PM, Arnd Bergmann wrote: > Using 64-bit time_t on x32 is fine, because it's fast to operate > in user space with 64-bit registers, and the kernel is 64-bit > anyway. Inside of the kernel, we may get into trouble using > a 64-bit time_t on 32-bit architectures because of the overhead > in 64-bit math, e.g. all the timekeeping code that is based on > timespec or some code paths in file systems and network code where > we actually require division of time_t values. While going over time_t uses, have you found a pattern for use cases involving division of time_t values in filesystem and networking code? >>> >>> In ipv4, we have multiple places doing this: >>> >>> icmp_param.data.times[1] = htonl((tv.tv_sec % 86400) * MSEC_PER_SEC >>> + >>> tv.tv_nsec / NSEC_PER_MSEC); >>> >>> to calculate the miliseconds since midnight. For file systems, I >>> found that FAT uses seconds/minutes/hours/days/month/year representation, >>> which is a lot of divides, but that can probably be optimized and >>> we need to handle years beyond 2038 anyway. >> >> We can do some tricks for internal optimizations here if these are >> critical. I'd be more concerned about userland divisions where moving >> to a 64bit time_t would cause performance issues that we cannot help >> optimize. > > Good point. > > We clearly have to change that code in some for to deal with y2038, > but 64-bit time_t may not be the best option. A lot of the > in-kernel code can probably use ktime_t, which we can change > to a different representation (e.g. 34 bit seconds) if needed, > and all the code that is only interested in relative time > (e.g. nanosleep) doesn't have to change at all. Yeah. 32-bit uptimes should be good enough for everyone (don't quote me on that), so adding a 64-bit offset when there's a need for absolute time should be OK. >>> >>> I think we have three categories: >>> >>> a) interfaces that uses relative time_t/timespec/timeval: >>>- nanosleep >>>- select/pselect/poll/ppoll/epoll >>>- getrusage >>>- sched_rr_get_interval >>>- sigtimedwait >>>- clock_nanosleep >>>- alarm >>>- siginfo (rusage) >>> >>> These can stay compatible, but we'd have to use a different >>> type if we change time_t. >> >> >> So as a correction, at least clock_nanosleep can specify sleep times >> using absolute time. > > Thanks. > >>> b) interfaces that don't make sense for times in the past: >>>- getitimer/setitimer >>>- timer_settime/timer_gettime >>>- gettimeofday/settimeofday >>>- adjtimex >>>- clock_gettime/clock_settime/clock_adjtime >>>- time/stime >>>- socket time stamps >>>- audio time stamps >>>- v4l time stamps >>>- input event time stamps >>>- sysv ipc (msg, sem, shm) >>> >>>Here, we are relatively free to change the start of the >>>epoch in the kernel but convert to something else on the >>>user space boundary. One possibility is to scale them to >>>boot time and use ktime_t in the kernel. >> >> I'm not sure I'm totally following this... Are you suggesting we keep >> 32bit time internally w/ some different offset but then pass to >> userland a 64bit time_t? Or are you suggesting we change the abi to >> move the epoch? > > What I meant is that regardless of what we decide for the ABI, > we can change the in-kernel representation in any way we like as > long as we can represent all dates that can occur during the runtime > of the kernel, i.e. we don't have to represent times between 1970 and > 2014. This could mean one of many representations: > > - time_t scaled forward by 44 years and/or made unsigned > - ktime_t scaled to boot time > - 64-bit nanoseconds starting at the epoch > - timespec64 > >> I think I'm with hpa in his recent mail in that the internal >> representation is an optimization detail, and the bigger question is >> do we use a 64bit time_t for future systems (possibly w/ a major ABI >> break - with compat interface for existing 32bit applications), or do >> we try to rev interfaces function by function to provide 2038 safe >> versions which applications will have to be modified to use? >> >> Me, I'm a fan of moving time_t to 64bits, since it makes "porting" >> applications to a 2038 safe ABI easier. > > I think there are two or three distinct problems: > > a) We absolutely have to find a way to build a user space that >can survive 2038. This probably involves moving at least >time_t, timeval and timespec to use 64-bit representation. > b) We have to keep compatibility with existing user space running >on future kernels, which means at
Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
On 2014/5/15 07:08 PM, Arnd Bergmann wrote: > On Wednesday 14 May 2014 14:33:18 John Stultz wrote: >> On Tue, May 13, 2014 at 12:32 PM, Arnd Bergmann wrote: >>> On Tuesday 13 May 2014 20:24:59 Geert Uytterhoeven wrote: On Tue, May 13, 2014 at 8:10 PM, Arnd Bergmann wrote: > Using 64-bit time_t on x32 is fine, because it's fast to operate > in user space with 64-bit registers, and the kernel is 64-bit > anyway. Inside of the kernel, we may get into trouble using > a 64-bit time_t on 32-bit architectures because of the overhead > in 64-bit math, e.g. all the timekeeping code that is based on > timespec or some code paths in file systems and network code where > we actually require division of time_t values. While going over time_t uses, have you found a pattern for use cases involving division of time_t values in filesystem and networking code? >>> >>> In ipv4, we have multiple places doing this: >>> >>> icmp_param.data.times[1] = htonl((tv.tv_sec % 86400) * MSEC_PER_SEC >>> + >>> tv.tv_nsec / NSEC_PER_MSEC); >>> >>> to calculate the miliseconds since midnight. For file systems, I >>> found that FAT uses seconds/minutes/hours/days/month/year representation, >>> which is a lot of divides, but that can probably be optimized and >>> we need to handle years beyond 2038 anyway. >> >> We can do some tricks for internal optimizations here if these are >> critical. I'd be more concerned about userland divisions where moving >> to a 64bit time_t would cause performance issues that we cannot help >> optimize. > > Good point. > > We clearly have to change that code in some for to deal with y2038, > but 64-bit time_t may not be the best option. A lot of the > in-kernel code can probably use ktime_t, which we can change > to a different representation (e.g. 34 bit seconds) if needed, > and all the code that is only interested in relative time > (e.g. nanosleep) doesn't have to change at all. Yeah. 32-bit uptimes should be good enough for everyone (don't quote me on that), so adding a 64-bit offset when there's a need for absolute time should be OK. >>> >>> I think we have three categories: >>> >>> a) interfaces that uses relative time_t/timespec/timeval: >>>- nanosleep >>>- select/pselect/poll/ppoll/epoll >>>- getrusage >>>- sched_rr_get_interval >>>- sigtimedwait >>>- clock_nanosleep >>>- alarm >>>- siginfo (rusage) >>> >>> These can stay compatible, but we'd have to use a different >>> type if we change time_t. >> >> >> So as a correction, at least clock_nanosleep can specify sleep times >> using absolute time. > > Thanks. > >>> b) interfaces that don't make sense for times in the past: >>>- getitimer/setitimer >>>- timer_settime/timer_gettime >>>- gettimeofday/settimeofday >>>- adjtimex >>>- clock_gettime/clock_settime/clock_adjtime >>>- time/stime >>>- socket time stamps >>>- audio time stamps >>>- v4l time stamps >>>- input event time stamps >>>- sysv ipc (msg, sem, shm) >>> >>>Here, we are relatively free to change the start of the >>>epoch in the kernel but convert to something else on the >>>user space boundary. One possibility is to scale them to >>>boot time and use ktime_t in the kernel. >> >> I'm not sure I'm totally following this... Are you suggesting we keep >> 32bit time internally w/ some different offset but then pass to >> userland a 64bit time_t? Or are you suggesting we change the abi to >> move the epoch? > > What I meant is that regardless of what we decide for the ABI, > we can change the in-kernel representation in any way we like as > long as we can represent all dates that can occur during the runtime > of the kernel, i.e. we don't have to represent times between 1970 and > 2014. This could mean one of many representations: > > - time_t scaled forward by 44 years and/or made unsigned > - ktime_t scaled to boot time > - 64-bit nanoseconds starting at the epoch > - timespec64 > >> I think I'm with hpa in his recent mail in that the internal >> representation is an optimization detail, and the bigger question is >> do we use a 64bit time_t for future systems (possibly w/ a major ABI >> break - with compat interface for existing 32bit applications), or do >> we try to rev interfaces function by function to provide 2038 safe >> versions which applications will have to be modified to use? >> >> Me, I'm a fan of moving time_t to 64bits, since it makes "porting" >> applications to a 2038 safe ABI easier. > > I think there are two or three distinct problems: > > a) We absolutely have to find a way to build a user space that >can survive 2038. This probably involves moving at least >time_t, timeval and timespec to use 64-bit representation. > b) We have to keep compatibility with existing user space running >on future kernels, which means at
Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
On 2014/5/15 07:08 PM, Arnd Bergmann wrote: On Wednesday 14 May 2014 14:33:18 John Stultz wrote: On Tue, May 13, 2014 at 12:32 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 13 May 2014 20:24:59 Geert Uytterhoeven wrote: On Tue, May 13, 2014 at 8:10 PM, Arnd Bergmann a...@arndb.de wrote: Using 64-bit time_t on x32 is fine, because it's fast to operate in user space with 64-bit registers, and the kernel is 64-bit anyway. Inside of the kernel, we may get into trouble using a 64-bit time_t on 32-bit architectures because of the overhead in 64-bit math, e.g. all the timekeeping code that is based on timespec or some code paths in file systems and network code where we actually require division of time_t values. While going over time_t uses, have you found a pattern for use cases involving division of time_t values in filesystem and networking code? In ipv4, we have multiple places doing this: icmp_param.data.times[1] = htonl((tv.tv_sec % 86400) * MSEC_PER_SEC + tv.tv_nsec / NSEC_PER_MSEC); to calculate the miliseconds since midnight. For file systems, I found that FAT uses seconds/minutes/hours/days/month/year representation, which is a lot of divides, but that can probably be optimized and we need to handle years beyond 2038 anyway. We can do some tricks for internal optimizations here if these are critical. I'd be more concerned about userland divisions where moving to a 64bit time_t would cause performance issues that we cannot help optimize. Good point. We clearly have to change that code in some for to deal with y2038, but 64-bit time_t may not be the best option. A lot of the in-kernel code can probably use ktime_t, which we can change to a different representation (e.g. 34 bit seconds) if needed, and all the code that is only interested in relative time (e.g. nanosleep) doesn't have to change at all. Yeah. 32-bit uptimes should be good enough for everyone (don't quote me on that), so adding a 64-bit offset when there's a need for absolute time should be OK. I think we have three categories: a) interfaces that uses relative time_t/timespec/timeval: - nanosleep - select/pselect/poll/ppoll/epoll - getrusage - sched_rr_get_interval - sigtimedwait - clock_nanosleep - alarm - siginfo (rusage) These can stay compatible, but we'd have to use a different type if we change time_t. So as a correction, at least clock_nanosleep can specify sleep times using absolute time. Thanks. b) interfaces that don't make sense for times in the past: - getitimer/setitimer - timer_settime/timer_gettime - gettimeofday/settimeofday - adjtimex - clock_gettime/clock_settime/clock_adjtime - time/stime - socket time stamps - audio time stamps - v4l time stamps - input event time stamps - sysv ipc (msg, sem, shm) Here, we are relatively free to change the start of the epoch in the kernel but convert to something else on the user space boundary. One possibility is to scale them to boot time and use ktime_t in the kernel. I'm not sure I'm totally following this... Are you suggesting we keep 32bit time internally w/ some different offset but then pass to userland a 64bit time_t? Or are you suggesting we change the abi to move the epoch? What I meant is that regardless of what we decide for the ABI, we can change the in-kernel representation in any way we like as long as we can represent all dates that can occur during the runtime of the kernel, i.e. we don't have to represent times between 1970 and 2014. This could mean one of many representations: - time_t scaled forward by 44 years and/or made unsigned - ktime_t scaled to boot time - 64-bit nanoseconds starting at the epoch - timespec64 I think I'm with hpa in his recent mail in that the internal representation is an optimization detail, and the bigger question is do we use a 64bit time_t for future systems (possibly w/ a major ABI break - with compat interface for existing 32bit applications), or do we try to rev interfaces function by function to provide 2038 safe versions which applications will have to be modified to use? Me, I'm a fan of moving time_t to 64bits, since it makes porting applications to a 2038 safe ABI easier. I think there are two or three distinct problems: a) We absolutely have to find a way to build a user space that can survive 2038. This probably involves moving at least time_t, timeval and timespec to use 64-bit representation. b) We have to keep compatibility with existing user space running on future kernels, which means at least x86, arm and a few other 32-bit architectures (we can ignore some of the obsolete ones if that helps us) need to provide syscall ABIs for both 32-bit time_t and whatever we use for the new syscalls and ioctls. As Thomas said, for some interfaces this could
Re: [PATCH 00/25] Change time_t and clock_t to 64 bit
On 2014/5/15 07:08 PM, Arnd Bergmann wrote: On Wednesday 14 May 2014 14:33:18 John Stultz wrote: On Tue, May 13, 2014 at 12:32 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 13 May 2014 20:24:59 Geert Uytterhoeven wrote: On Tue, May 13, 2014 at 8:10 PM, Arnd Bergmann a...@arndb.de wrote: Using 64-bit time_t on x32 is fine, because it's fast to operate in user space with 64-bit registers, and the kernel is 64-bit anyway. Inside of the kernel, we may get into trouble using a 64-bit time_t on 32-bit architectures because of the overhead in 64-bit math, e.g. all the timekeeping code that is based on timespec or some code paths in file systems and network code where we actually require division of time_t values. While going over time_t uses, have you found a pattern for use cases involving division of time_t values in filesystem and networking code? In ipv4, we have multiple places doing this: icmp_param.data.times[1] = htonl((tv.tv_sec % 86400) * MSEC_PER_SEC + tv.tv_nsec / NSEC_PER_MSEC); to calculate the miliseconds since midnight. For file systems, I found that FAT uses seconds/minutes/hours/days/month/year representation, which is a lot of divides, but that can probably be optimized and we need to handle years beyond 2038 anyway. We can do some tricks for internal optimizations here if these are critical. I'd be more concerned about userland divisions where moving to a 64bit time_t would cause performance issues that we cannot help optimize. Good point. We clearly have to change that code in some for to deal with y2038, but 64-bit time_t may not be the best option. A lot of the in-kernel code can probably use ktime_t, which we can change to a different representation (e.g. 34 bit seconds) if needed, and all the code that is only interested in relative time (e.g. nanosleep) doesn't have to change at all. Yeah. 32-bit uptimes should be good enough for everyone (don't quote me on that), so adding a 64-bit offset when there's a need for absolute time should be OK. I think we have three categories: a) interfaces that uses relative time_t/timespec/timeval: - nanosleep - select/pselect/poll/ppoll/epoll - getrusage - sched_rr_get_interval - sigtimedwait - clock_nanosleep - alarm - siginfo (rusage) These can stay compatible, but we'd have to use a different type if we change time_t. So as a correction, at least clock_nanosleep can specify sleep times using absolute time. Thanks. b) interfaces that don't make sense for times in the past: - getitimer/setitimer - timer_settime/timer_gettime - gettimeofday/settimeofday - adjtimex - clock_gettime/clock_settime/clock_adjtime - time/stime - socket time stamps - audio time stamps - v4l time stamps - input event time stamps - sysv ipc (msg, sem, shm) Here, we are relatively free to change the start of the epoch in the kernel but convert to something else on the user space boundary. One possibility is to scale them to boot time and use ktime_t in the kernel. I'm not sure I'm totally following this... Are you suggesting we keep 32bit time internally w/ some different offset but then pass to userland a 64bit time_t? Or are you suggesting we change the abi to move the epoch? What I meant is that regardless of what we decide for the ABI, we can change the in-kernel representation in any way we like as long as we can represent all dates that can occur during the runtime of the kernel, i.e. we don't have to represent times between 1970 and 2014. This could mean one of many representations: - time_t scaled forward by 44 years and/or made unsigned - ktime_t scaled to boot time - 64-bit nanoseconds starting at the epoch - timespec64 I think I'm with hpa in his recent mail in that the internal representation is an optimization detail, and the bigger question is do we use a 64bit time_t for future systems (possibly w/ a major ABI break - with compat interface for existing 32bit applications), or do we try to rev interfaces function by function to provide 2038 safe versions which applications will have to be modified to use? Me, I'm a fan of moving time_t to 64bits, since it makes porting applications to a 2038 safe ABI easier. I think there are two or three distinct problems: a) We absolutely have to find a way to build a user space that can survive 2038. This probably involves moving at least time_t, timeval and timespec to use 64-bit representation. b) We have to keep compatibility with existing user space running on future kernels, which means at least x86, arm and a few other 32-bit architectures (we can ignore some of the obsolete ones if that helps us) need to provide syscall ABIs for both 32-bit time_t and whatever we use for the new syscalls and ioctls. As Thomas said, for some interfaces this could
Re: [PATCH 00/28] nios2 Linux kernel port
On 14/4/25 下午4:37, Pinski, Andrew wrote: > > >> On Apr 24, 2014, at 11:06 PM, "Chung-Lin Tang" >> wrote: >> >>> On 2014/4/25 02:42 AM, Pinski, Andrew wrote: >>> >>> >>>>> On Apr 24, 2014, at 11:37 AM, "Chung-Lin Tang" >>>>> wrote: >>>>> >>>>>> On 2014/4/24 11:28 PM, Catalin Marinas wrote: >>>>>>> On Thu, Apr 24, 2014 at 09:55:25AM +0100, Chung-Lin Tang wrote: >>>>>>>> On 2014/4/24 02:26 PM, Chung-Lin Tang wrote: >>>>>>>> On 2014/4/24 上午 02:15, Pinski, Andrew wrote: >>>>>>>> >>>>>>>>>> On Apr 23, 2014, at 10:59 AM, "Chung-Lin Tang" >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>>> On 2014/4/22 07:20 PM, Ley Foon Tan wrote: >>>>>>>>>>>> On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann >>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: >>>>>>>>>>>>>>>>>>>> Hi Arnd and Peter Anvin, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Other than 64-bit time_t, clock_t and suseconds_t, can you >>>>>>>>>>>>>>>>>>>> confirm >>>>>>>>>>>>>>>>>>>> that we don't need to have 64 bit off_t? See detail in >>>>>>>>>>>>>>>>>>>> link below. >>>>>>>>>>>>>>>>>>>> I can submit the patches for 64-bit time changes >>>>>>>>>>>>>>>>>>>> (include/asm-generic/posix_types.h and other archs) if >>>>>>>>>>>>>>>>>>>> everyone is >>>>>>>>>>>>>>>>>>>> agreed on this. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yes. >>>>>>>>>>>> Okay, will doing that. >>>>>>>>>> >>>>>>>>>> I believe that arm64 ILP32 will also be affected. What is the status >>>>>>>>>> of >>>>>>>>>> this configuration? Has the glibc/kernel ABI been finalized? >>>>>>>> Not yet. I am still working out the signal handling part. But we >>>>>>>> already agreed on 64bit time_t, clock_t, and suseconds_t. And we >>>>>>>> agreed to a 64bit offset_t too. >>>>>>>> >>>>>>>> On a related note suseconds in the timespec in posix is defined to >>>>>>>> be long. So it would nice if the kernel ignores the upper 32bits so >>>>>>>> we (glibc developers) can fix this for new targets including x32 >>>>>>>> and arm64/ilp32. >>>>>>> >>>>>>> Hmm, but that means for purely 32-bit architectures like nios2, which >>>>>>> unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit >>>>>>> type in the kernel is simply wasted. >>>>>> >>>>>> The more I think of this, the more I feel that suseconds_t should jsut >>>>>> be 'long', not strictly 64-bitified. An ILP32 sub-mode in a 64-bit >>>>>> kernel should be using compat_* code paths, something like a >>>>>> COMPAT_USE_32BIT_SUSECONDS case. >>>>> >>>>> ILP32 mode should use LP64 syscalls as much as possible and that's the >>>>> aim with arm64 as well (of course, we still have a few that wouldn't be >>>>> possible and we route them via compat). >>>>> >>>>> But here if time_t is 64-bit while susecconds_t is 32-bit, the compat >>>>> code wouldn't help. >>>> >>>> Why not? You can define the arm64 'struct compat_timeval' with >>>> suseconds_t as s32, and add the 32<-->64 case in the >>>> compat_get/put_timeval path, triggered when the process is ILP32 (test >>>> wrapped in the above hypothetical COMPAT_USE_32BIT_SUSECONDS macro). >>>> Similar to how x32 does COMPAT_USE_
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/25 02:42 AM, Pinski, Andrew wrote: > > >> On Apr 24, 2014, at 11:37 AM, "Chung-Lin Tang" >> wrote: >> >>> On 2014/4/24 11:28 PM, Catalin Marinas wrote: >>>> On Thu, Apr 24, 2014 at 09:55:25AM +0100, Chung-Lin Tang wrote: >>>>> On 2014/4/24 02:26 PM, Chung-Lin Tang wrote: >>>>>> On 2014/4/24 上午 02:15, Pinski, Andrew wrote: >>>>>> >>>>>>>> On Apr 23, 2014, at 10:59 AM, "Chung-Lin Tang" >>>>>>>> wrote: >>>>>>>> >>>>>>>>>> On 2014/4/22 07:20 PM, Ley Foon Tan wrote: >>>>>>>>>> On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann wrote: >>>>>>>>>>>>>> On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: >>>>>>>>>>>>>>>>>> Hi Arnd and Peter Anvin, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Other than 64-bit time_t, clock_t and suseconds_t, can you >>>>>>>>>>>>>>>>>> confirm >>>>>>>>>>>>>>>>>> that we don't need to have 64 bit off_t? See detail in link >>>>>>>>>>>>>>>>>> below. >>>>>>>>>>>>>>>>>> I can submit the patches for 64-bit time changes >>>>>>>>>>>>>>>>>> (include/asm-generic/posix_types.h and other archs) if >>>>>>>>>>>>>>>>>> everyone is >>>>>>>>>>>>>>>>>> agreed on this. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes. >>>>>>>>>> Okay, will doing that. >>>>>>>> >>>>>>>> I believe that arm64 ILP32 will also be affected. What is the status of >>>>>>>> this configuration? Has the glibc/kernel ABI been finalized? >>>>>> Not yet. I am still working out the signal handling part. But we >>>>>> already agreed on 64bit time_t, clock_t, and suseconds_t. And we >>>>>> agreed to a 64bit offset_t too. >>>>>> >>>>>> On a related note suseconds in the timespec in posix is defined to >>>>>> be long. So it would nice if the kernel ignores the upper 32bits so >>>>>> we (glibc developers) can fix this for new targets including x32 >>>>>> and arm64/ilp32. >>>>> >>>>> Hmm, but that means for purely 32-bit architectures like nios2, which >>>>> unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit >>>>> type in the kernel is simply wasted. >>>> >>>> The more I think of this, the more I feel that suseconds_t should jsut >>>> be 'long', not strictly 64-bitified. An ILP32 sub-mode in a 64-bit >>>> kernel should be using compat_* code paths, something like a >>>> COMPAT_USE_32BIT_SUSECONDS case. >>> >>> ILP32 mode should use LP64 syscalls as much as possible and that's the >>> aim with arm64 as well (of course, we still have a few that wouldn't be >>> possible and we route them via compat). >>> >>> But here if time_t is 64-bit while susecconds_t is 32-bit, the compat >>> code wouldn't help. >> >> Why not? You can define the arm64 'struct compat_timeval' with >> suseconds_t as s32, and add the 32<-->64 case in the >> compat_get/put_timeval path, triggered when the process is ILP32 (test >> wrapped in the above hypothetical COMPAT_USE_32BIT_SUSECONDS macro). >> Similar to how x32 does COMPAT_USE_64BIT_TIME. > > We would three timeval then. One for aarch32, one for lp64 and one for ilp32. > We really don't want three. Two is already one too many in my mind after > developing the ilp32 syscall abi. > > Thanks, > Andrew Okay I now see you're already doing that for 32-bit ARM. Still, you would probably just need to have an arm64-ILP32 specific case to be careful about the last padding word upon kernel entry/exit. (accommodating the difference in sizeof(long)) Penalizing all architectures does not seem like the best solution. Having suseconds_t as a strictly 64-bit C type in the kernel, while defined as <= long in user-space may cause other problems. I'll try to explain a probable situation for Nios II. I'm not sure about other soft-cores, but nios2 is sort of uncommon in that the maximum alignment is 4-bytes (32-bits), even for doubles/long-longs. So if time_t is 64-bits (which makes sense), then struct timeval, which is time_t+suseconds_t in userspace is 12-bytes/aligned-4 (unlike many archs where a 64-bit time_t will expand the size to 16-bytes, due to align-8) If the kernel suseconds_t is forced to be 64-bits, then nios2 will have a 16-byte kernel timeval vs. 12-byte userspace timeval situation. Just this will require us to do something using compat_*, or weird hacks in glibc, which is unfair. Nios II has no "other-mode". We are just strictly ILP32, everywhere. Of course, we can probably still at the end just use a Nios II specific posix_types.h header to override things, but I'm just stating this as a matter of which are the most reasonable default settings in the generic headers. Making pure ILP32 archs diverge from POSIX standards by default does not seem to be right. Thanks, Chung-Lin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/25 02:42 AM, Pinski, Andrew wrote: On Apr 24, 2014, at 11:37 AM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/24 11:28 PM, Catalin Marinas wrote: On Thu, Apr 24, 2014 at 09:55:25AM +0100, Chung-Lin Tang wrote: On 2014/4/24 02:26 PM, Chung-Lin Tang wrote: On 2014/4/24 上午 02:15, Pinski, Andrew wrote: On Apr 23, 2014, at 10:59 AM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/22 07:20 PM, Ley Foon Tan wrote: On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Yes. Okay, will doing that. I believe that arm64 ILP32 will also be affected. What is the status of this configuration? Has the glibc/kernel ABI been finalized? Not yet. I am still working out the signal handling part. But we already agreed on 64bit time_t, clock_t, and suseconds_t. And we agreed to a 64bit offset_t too. On a related note suseconds in the timespec in posix is defined to be long. So it would nice if the kernel ignores the upper 32bits so we (glibc developers) can fix this for new targets including x32 and arm64/ilp32. Hmm, but that means for purely 32-bit architectures like nios2, which unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit type in the kernel is simply wasted. The more I think of this, the more I feel that suseconds_t should jsut be 'long', not strictly 64-bitified. An ILP32 sub-mode in a 64-bit kernel should be using compat_* code paths, something like a COMPAT_USE_32BIT_SUSECONDS case. ILP32 mode should use LP64 syscalls as much as possible and that's the aim with arm64 as well (of course, we still have a few that wouldn't be possible and we route them via compat). But here if time_t is 64-bit while susecconds_t is 32-bit, the compat code wouldn't help. Why not? You can define the arm64 'struct compat_timeval' with suseconds_t as s32, and add the 32--64 case in the compat_get/put_timeval path, triggered when the process is ILP32 (test wrapped in the above hypothetical COMPAT_USE_32BIT_SUSECONDS macro). Similar to how x32 does COMPAT_USE_64BIT_TIME. We would three timeval then. One for aarch32, one for lp64 and one for ilp32. We really don't want three. Two is already one too many in my mind after developing the ilp32 syscall abi. Thanks, Andrew Okay I now see you're already doing that for 32-bit ARM. Still, you would probably just need to have an arm64-ILP32 specific case to be careful about the last padding word upon kernel entry/exit. (accommodating the difference in sizeof(long)) Penalizing all architectures does not seem like the best solution. Having suseconds_t as a strictly 64-bit C type in the kernel, while defined as = long in user-space may cause other problems. I'll try to explain a probable situation for Nios II. I'm not sure about other soft-cores, but nios2 is sort of uncommon in that the maximum alignment is 4-bytes (32-bits), even for doubles/long-longs. So if time_t is 64-bits (which makes sense), then struct timeval, which is time_t+suseconds_t in userspace is 12-bytes/aligned-4 (unlike many archs where a 64-bit time_t will expand the size to 16-bytes, due to align-8) If the kernel suseconds_t is forced to be 64-bits, then nios2 will have a 16-byte kernel timeval vs. 12-byte userspace timeval situation. Just this will require us to do something using compat_*, or weird hacks in glibc, which is unfair. Nios II has no other-mode. We are just strictly ILP32, everywhere. Of course, we can probably still at the end just use a Nios II specific posix_types.h header to override things, but I'm just stating this as a matter of which are the most reasonable default settings in the generic headers. Making pure ILP32 archs diverge from POSIX standards by default does not seem to be right. Thanks, Chung-Lin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 14/4/25 下午4:37, Pinski, Andrew wrote: On Apr 24, 2014, at 11:06 PM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/25 02:42 AM, Pinski, Andrew wrote: On Apr 24, 2014, at 11:37 AM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/24 11:28 PM, Catalin Marinas wrote: On Thu, Apr 24, 2014 at 09:55:25AM +0100, Chung-Lin Tang wrote: On 2014/4/24 02:26 PM, Chung-Lin Tang wrote: On 2014/4/24 上午 02:15, Pinski, Andrew wrote: On Apr 23, 2014, at 10:59 AM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/22 07:20 PM, Ley Foon Tan wrote: On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Yes. Okay, will doing that. I believe that arm64 ILP32 will also be affected. What is the status of this configuration? Has the glibc/kernel ABI been finalized? Not yet. I am still working out the signal handling part. But we already agreed on 64bit time_t, clock_t, and suseconds_t. And we agreed to a 64bit offset_t too. On a related note suseconds in the timespec in posix is defined to be long. So it would nice if the kernel ignores the upper 32bits so we (glibc developers) can fix this for new targets including x32 and arm64/ilp32. Hmm, but that means for purely 32-bit architectures like nios2, which unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit type in the kernel is simply wasted. The more I think of this, the more I feel that suseconds_t should jsut be 'long', not strictly 64-bitified. An ILP32 sub-mode in a 64-bit kernel should be using compat_* code paths, something like a COMPAT_USE_32BIT_SUSECONDS case. ILP32 mode should use LP64 syscalls as much as possible and that's the aim with arm64 as well (of course, we still have a few that wouldn't be possible and we route them via compat). But here if time_t is 64-bit while susecconds_t is 32-bit, the compat code wouldn't help. Why not? You can define the arm64 'struct compat_timeval' with suseconds_t as s32, and add the 32--64 case in the compat_get/put_timeval path, triggered when the process is ILP32 (test wrapped in the above hypothetical COMPAT_USE_32BIT_SUSECONDS macro). Similar to how x32 does COMPAT_USE_64BIT_TIME. We would three timeval then. One for aarch32, one for lp64 and one for ilp32. We really don't want three. Two is already one too many in my mind after developing the ilp32 syscall abi. Thanks, Andrew Okay I now see you're already doing that for 32-bit ARM. Still, you would probably just need to have an arm64-ILP32 specific case to be careful about the last padding word upon kernel entry/exit. (accommodating the difference in sizeof(long)) Penalizing all architectures does not seem like the best solution. Considering the alignment of long long would be 64bits, the struct does not change sizes if suseconds_t is 32bits or 64bits. Having suseconds_t as a strictly 64-bit C type in the kernel, while defined as = long in user-space may cause other problems. I'll try to explain a probable situation for Nios II. I'm not sure about other soft-cores, but nios2 is sort of uncommon in that the maximum alignment is 4-bytes (32-bits), even for doubles/long-longs. Yes does that include even if users of aligned? If so that seems broken. Also yes nios ii is unstandard when it comes to alignment here. You mean using '__attribute__((aligned(8)))'? Sure of course that enlarges the alignment as expected, but sprinkling that over glibc, or getting it into the main glibc bits/time.h header is probably not going to happen... Thanks, Chung-Lin So if time_t is 64-bits (which makes sense), then struct timeval, which is time_t+suseconds_t in userspace is 12-bytes/aligned-4 (unlike many archs where a 64-bit time_t will expand the size to 16-bytes, due to align-8) Unlike most other targets where the struct would 16bits no matter what. Thanks, Andrew If the kernel suseconds_t is forced to be 64-bits, then nios2 will have a 16-byte kernel timeval vs. 12-byte userspace timeval situation. Just this will require us to do something using compat_*, or weird hacks in glibc, which is unfair. Nios II has no other-mode. We are just strictly ILP32, everywhere. Of course, we can probably still at the end just use a Nios II specific posix_types.h header to override things, but I'm just stating this as a matter of which are the most reasonable default settings in the generic headers. Making pure ILP32 archs diverge from POSIX standards by default does not seem to be right. Thanks, Chung-Lin -- To unsubscribe from this list: send the line
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/24 11:28 PM, Catalin Marinas wrote: > On Thu, Apr 24, 2014 at 09:55:25AM +0100, Chung-Lin Tang wrote: >> On 2014/4/24 02:26 PM, Chung-Lin Tang wrote: >>> On 2014/4/24 上午 02:15, Pinski, Andrew wrote: >>>> >>>>>> On Apr 23, 2014, at 10:59 AM, "Chung-Lin Tang" >>>>>> wrote: >>>>>> >>>>>>>> On 2014/4/22 07:20 PM, Ley Foon Tan wrote: >>>>>>>> On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann wrote: >>>>>>>>>>>> On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: >>>>>>>>>>>>>>>> Hi Arnd and Peter Anvin, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Other than 64-bit time_t, clock_t and suseconds_t, can you >>>>>>>>>>>>>>>> confirm >>>>>>>>>>>>>>>> that we don't need to have 64 bit off_t? See detail in link >>>>>>>>>>>>>>>> below. >>>>>>>>>>>>>>>> I can submit the patches for 64-bit time changes >>>>>>>>>>>>>>>> (include/asm-generic/posix_types.h and other archs) if >>>>>>>>>>>>>>>> everyone is >>>>>>>>>>>>>>>> agreed on this. >>>>>>>>>>>> >>>>>>>>>>>> Yes. >>>>>>>> Okay, will doing that. >>>>>> >>>>>> I believe that arm64 ILP32 will also be affected. What is the status of >>>>>> this configuration? Has the glibc/kernel ABI been finalized? >>>> Not yet. I am still working out the signal handling part. But we >>>> already agreed on 64bit time_t, clock_t, and suseconds_t. And we >>>> agreed to a 64bit offset_t too. >>>> >>>> On a related note suseconds in the timespec in posix is defined to >>>> be long. So it would nice if the kernel ignores the upper 32bits so >>>> we (glibc developers) can fix this for new targets including x32 >>>> and arm64/ilp32. >>> >>> Hmm, but that means for purely 32-bit architectures like nios2, which >>> unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit >>> type in the kernel is simply wasted. >> >> The more I think of this, the more I feel that suseconds_t should jsut >> be 'long', not strictly 64-bitified. An ILP32 sub-mode in a 64-bit >> kernel should be using compat_* code paths, something like a >> COMPAT_USE_32BIT_SUSECONDS case. > > ILP32 mode should use LP64 syscalls as much as possible and that's the > aim with arm64 as well (of course, we still have a few that wouldn't be > possible and we route them via compat). > > But here if time_t is 64-bit while susecconds_t is 32-bit, the compat > code wouldn't help. Why not? You can define the arm64 'struct compat_timeval' with suseconds_t as s32, and add the 32<-->64 case in the compat_get/put_timeval path, triggered when the process is ILP32 (test wrapped in the above hypothetical COMPAT_USE_32BIT_SUSECONDS macro). Similar to how x32 does COMPAT_USE_64BIT_TIME. Chung-Lin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/24 02:26 PM, Chung-Lin Tang wrote: > On 2014/4/24 上午 02:15, Pinski, Andrew wrote: >> >>>> On Apr 23, 2014, at 10:59 AM, "Chung-Lin Tang" >>>> wrote: >>>> >>>>>> On 2014/4/22 07:20 PM, Ley Foon Tan wrote: >>>>>> On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann wrote: >>>>>>>>>> On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: >>>>>>>>>>>>>> Hi Arnd and Peter Anvin, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Other than 64-bit time_t, clock_t and suseconds_t, can you >>>>>>>>>>>>>> confirm >>>>>>>>>>>>>> that we don't need to have 64 bit off_t? See detail in link >>>>>>>>>>>>>> below. >>>>>>>>>>>>>> I can submit the patches for 64-bit time changes >>>>>>>>>>>>>> (include/asm-generic/posix_types.h and other archs) if everyone >>>>>>>>>>>>>> is >>>>>>>>>>>>>> agreed on this. >>>>>>>>>> >>>>>>>>>> Yes. >>>>>> Okay, will doing that. >>>> >>>> I believe that arm64 ILP32 will also be affected. What is the status of >>>> this configuration? Has the glibc/kernel ABI been finalized? >> Not yet. I am still working out the signal handling part. But we already >> agreed on 64bit time_t, clock_t, and suseconds_t. And we agreed to a 64bit >> offset_t too. >> >> On a related note suseconds in the timespec in posix is defined to be long. >> So it would nice if the kernel ignores the upper 32bits so we (glibc >> developers) can fix this for new targets including x32 and arm64/ilp32. > > Hmm, but that means for purely 32-bit architectures like nios2, which > unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit > type in the kernel is simply wasted. > > Chung-Lin The more I think of this, the more I feel that suseconds_t should jsut be 'long', not strictly 64-bitified. An ILP32 sub-mode in a 64-bit kernel should be using compat_* code paths, something like a COMPAT_USE_32BIT_SUSECONDS case. suseconds_t is for micro-seconds in struct timeval, 32-bit is more than enough. Chung-Lin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/24 上午 02:15, Pinski, Andrew wrote: > >> > On Apr 23, 2014, at 10:59 AM, "Chung-Lin Tang" >> > wrote: >> > >>> >> On 2014/4/22 07:20 PM, Ley Foon Tan wrote: >>> >> On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann wrote: >>>>> >>>> On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: >>>>>>> >>>>>> Hi Arnd and Peter Anvin, >>>>>>> >>>>>> >>>>>>> >>>>>> Other than 64-bit time_t, clock_t and suseconds_t, can you >>>>>>> >>>>>> confirm >>>>>>> >>>>>> that we don't need to have 64 bit off_t? See detail in link >>>>>>> >>>>>> below. >>>>>>> >>>>>> I can submit the patches for 64-bit time changes >>>>>>> >>>>>> (include/asm-generic/posix_types.h and other archs) if everyone >>>>>>> >>>>>> is >>>>>>> >>>>>> agreed on this. >>>>> >>>> >>>>> >>>> Yes. >>> >> Okay, will doing that. >> > >> > I believe that arm64 ILP32 will also be affected. What is the status of >> > this configuration? Has the glibc/kernel ABI been finalized? > Not yet. I am still working out the signal handling part. But we already > agreed on 64bit time_t, clock_t, and suseconds_t. And we agreed to a 64bit > offset_t too. > > On a related note suseconds in the timespec in posix is defined to be long. > So it would nice if the kernel ignores the upper 32bits so we (glibc > developers) can fix this for new targets including x32 and arm64/ilp32. Hmm, but that means for purely 32-bit architectures like nios2, which unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit type in the kernel is simply wasted. Chung-Lin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/24 上午 02:15, Pinski, Andrew wrote: On Apr 23, 2014, at 10:59 AM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/22 07:20 PM, Ley Foon Tan wrote: On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Yes. Okay, will doing that. I believe that arm64 ILP32 will also be affected. What is the status of this configuration? Has the glibc/kernel ABI been finalized? Not yet. I am still working out the signal handling part. But we already agreed on 64bit time_t, clock_t, and suseconds_t. And we agreed to a 64bit offset_t too. On a related note suseconds in the timespec in posix is defined to be long. So it would nice if the kernel ignores the upper 32bits so we (glibc developers) can fix this for new targets including x32 and arm64/ilp32. Hmm, but that means for purely 32-bit architectures like nios2, which unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit type in the kernel is simply wasted. Chung-Lin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/24 02:26 PM, Chung-Lin Tang wrote: On 2014/4/24 上午 02:15, Pinski, Andrew wrote: On Apr 23, 2014, at 10:59 AM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/22 07:20 PM, Ley Foon Tan wrote: On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Yes. Okay, will doing that. I believe that arm64 ILP32 will also be affected. What is the status of this configuration? Has the glibc/kernel ABI been finalized? Not yet. I am still working out the signal handling part. But we already agreed on 64bit time_t, clock_t, and suseconds_t. And we agreed to a 64bit offset_t too. On a related note suseconds in the timespec in posix is defined to be long. So it would nice if the kernel ignores the upper 32bits so we (glibc developers) can fix this for new targets including x32 and arm64/ilp32. Hmm, but that means for purely 32-bit architectures like nios2, which unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit type in the kernel is simply wasted. Chung-Lin The more I think of this, the more I feel that suseconds_t should jsut be 'long', not strictly 64-bitified. An ILP32 sub-mode in a 64-bit kernel should be using compat_* code paths, something like a COMPAT_USE_32BIT_SUSECONDS case. suseconds_t is for micro-seconds in struct timeval, 32-bit is more than enough. Chung-Lin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/24 11:28 PM, Catalin Marinas wrote: On Thu, Apr 24, 2014 at 09:55:25AM +0100, Chung-Lin Tang wrote: On 2014/4/24 02:26 PM, Chung-Lin Tang wrote: On 2014/4/24 上午 02:15, Pinski, Andrew wrote: On Apr 23, 2014, at 10:59 AM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/22 07:20 PM, Ley Foon Tan wrote: On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Yes. Okay, will doing that. I believe that arm64 ILP32 will also be affected. What is the status of this configuration? Has the glibc/kernel ABI been finalized? Not yet. I am still working out the signal handling part. But we already agreed on 64bit time_t, clock_t, and suseconds_t. And we agreed to a 64bit offset_t too. On a related note suseconds in the timespec in posix is defined to be long. So it would nice if the kernel ignores the upper 32bits so we (glibc developers) can fix this for new targets including x32 and arm64/ilp32. Hmm, but that means for purely 32-bit architectures like nios2, which unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit type in the kernel is simply wasted. The more I think of this, the more I feel that suseconds_t should jsut be 'long', not strictly 64-bitified. An ILP32 sub-mode in a 64-bit kernel should be using compat_* code paths, something like a COMPAT_USE_32BIT_SUSECONDS case. ILP32 mode should use LP64 syscalls as much as possible and that's the aim with arm64 as well (of course, we still have a few that wouldn't be possible and we route them via compat). But here if time_t is 64-bit while susecconds_t is 32-bit, the compat code wouldn't help. Why not? You can define the arm64 'struct compat_timeval' with suseconds_t as s32, and add the 32--64 case in the compat_get/put_timeval path, triggered when the process is ILP32 (test wrapped in the above hypothetical COMPAT_USE_32BIT_SUSECONDS macro). Similar to how x32 does COMPAT_USE_64BIT_TIME. Chung-Lin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/22 07:20 PM, Ley Foon Tan wrote: > On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann wrote: >> > On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: >>> >> Hi Arnd and Peter Anvin, >>> >> >>> >> Other than 64-bit time_t, clock_t and suseconds_t, can you confirm >>> >> that we don't need to have 64 bit off_t? See detail in link below. >>> >> I can submit the patches for 64-bit time changes >>> >> (include/asm-generic/posix_types.h and other archs) if everyone is >>> >> agreed on this. >> > >> > Yes. > Okay, will doing that. I believe that arm64 ILP32 will also be affected. What is the status of this configuration? Has the glibc/kernel ABI been finalized? Thanks, Chung-Lin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/22 07:20 PM, Ley Foon Tan wrote: On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Yes. Okay, will doing that. I believe that arm64 ILP32 will also be affected. What is the status of this configuration? Has the glibc/kernel ABI been finalized? Thanks, Chung-Lin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/28] nios2: Memory management
On 2014/4/23 上午 12:27, Ezequiel Garcia wrote: > On Apr 23, Chung-Lin Tang wrote: >> On 2014/4/22 下午 11:35, Ezequiel Garcia wrote: >>> On Apr 22, Tobias Klauser wrote: >>>> On 2014-04-22 at 16:24:43 +0200, Ezequiel Garcia >>>> wrote: >>>>> Hi Ley Foon, >>>>> >>>>> On Apr 18, Ley Foon Tan wrote: >>>>>> +/* >>>>>> + * PAGE_SHIFT determines the page size >>>>>> + */ >>>>>> +#define PAGE_SHIFT 12 >>>>>> +#define PAGE_SIZE 4096 >>>>>> +#define PAGE_MASK (~(PAGE_SIZE - 1)) >>>>>> + >>>>> >>>>> How about something like this: >>>>> >>>>> /* PAGE_SHIFT determines the page size */ >>>>> #define PAGE_SHIFT 12 >>>>> #define PAGE_SIZE (_AC(1,UL) << PAGE_SHIFT) >>>>> #define PAGE_MASK (~((1 << PAGE_SHIFT) - 1)) >>>>> >>>>> Otherwise, the PAGE_SIZE macro above produces some warnings, IIRC. >>>> >>>> AFAIR old nios2 GCC versions (the 4.1 version from Windriver, IIRC) >>>> would complain about something like the above, that's the reason I added >>>> an explicit value for PAGE_SIZE back then. >>>> >>> >>> Other than being "pretty" the above fix is to remove a mismatch type >>> warning. You can get rid of the warning in different ways: >>> >>> ifdef __ASSEMBLY__ >>> define PAGE_SIZE 4096 >>> else >>> define PAGE_SIZE 4096UL >>> endif >>> >>>> I assume with the new nios2 GCC this should no longer be necessary and >>>> Ezequiel's fix should be fine. >>> >>> Speaking of GCC... is there a libc available to test this kernel port? >>> (which I assume uses the generic syscall ABI) >> >> It's submitted to libc-alpha, also still review in progress. >> > > Do you plan to support uclibc? No, we (Mentor Graphics) are only doing glibc work at this point. Chung-Lin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/28] nios2: Memory management
On 2014/4/22 下午 11:35, Ezequiel Garcia wrote: > On Apr 22, Tobias Klauser wrote: >> On 2014-04-22 at 16:24:43 +0200, Ezequiel Garcia >> wrote: >>> Hi Ley Foon, >>> >>> On Apr 18, Ley Foon Tan wrote: +/* + * PAGE_SHIFT determines the page size + */ +#define PAGE_SHIFT12 +#define PAGE_SIZE 4096 +#define PAGE_MASK (~(PAGE_SIZE - 1)) + >>> >>> How about something like this: >>> >>> /* PAGE_SHIFT determines the page size */ >>> #define PAGE_SHIFT 12 >>> #define PAGE_SIZE (_AC(1,UL) << PAGE_SHIFT) >>> #define PAGE_MASK (~((1 << PAGE_SHIFT) - 1)) >>> >>> Otherwise, the PAGE_SIZE macro above produces some warnings, IIRC. >> >> AFAIR old nios2 GCC versions (the 4.1 version from Windriver, IIRC) >> would complain about something like the above, that's the reason I added >> an explicit value for PAGE_SIZE back then. >> > > Other than being "pretty" the above fix is to remove a mismatch type > warning. You can get rid of the warning in different ways: > > ifdef __ASSEMBLY__ > define PAGE_SIZE 4096 > else > define PAGE_SIZE 4096UL > endif > >> I assume with the new nios2 GCC this should no longer be necessary and >> Ezequiel's fix should be fine. > > Speaking of GCC... is there a libc available to test this kernel port? > (which I assume uses the generic syscall ABI) It's submitted to libc-alpha, also still review in progress. Chung-Lin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/22 07:20 PM, Ley Foon Tan wrote: > On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann wrote: >> On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: >>> Hi Arnd and Peter Anvin, >>> >>> Other than 64-bit time_t, clock_t and suseconds_t, can you confirm >>> that we don't need to have 64 bit off_t? See detail in link below. >>> I can submit the patches for 64-bit time changes >>> (include/asm-generic/posix_types.h and other archs) if everyone is >>> agreed on this. >> >> Yes. > Okay, will doing that. > >> >>> Excerpt from https://lkml.org/lkml/2012/11/14/358 : >>> "Obviously, we want to use 64-bit off_t, but this is achieved already >>> through loff_t, which is used in all places in the asm-generic >>> ABI anyway (the syscalls using off_t are stripped out). I don't >>> think we want to have the other ones set to 64 bit on ARC or Meta, >>> although I'm not 100% sure about ino_t and nlink_t. " >> >> This is all still true. You should have no syscall using 'off_t', >> only loff_t. >> >> I still don't know whether we would want 32 or 64 bit ino_t and nlink_t >> for new architectures. It seems it would gain very little, but have >> a noticeable overhead. > Anyone have comment on this? > Chung-Lin (in CC list) is our nios2 toolchain maintainer. Do you have > any comment for 32 or 64 bit ino_t and nlink_t? > We will update the toolchain to support 64-bit time_t, so we hope that > any other toolchain change can happen in one time. For ino_t, 32-bit users of linux-generic glibc already use struct stat64, stat64(), etc. to align with 64-bit targets, so in terms of the glibc/kernel interface it doesn't matter much. The in-kernel usage of the ino_t type should be of more concern here. nlink_t appears to be always defined as u32 in , not sure if changing it to arch-overridable is reasonable. Chung-Lin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/22 07:20 PM, Ley Foon Tan wrote: On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Yes. Okay, will doing that. Excerpt from https://lkml.org/lkml/2012/11/14/358 : Obviously, we want to use 64-bit off_t, but this is achieved already through loff_t, which is used in all places in the asm-generic ABI anyway (the syscalls using off_t are stripped out). I don't think we want to have the other ones set to 64 bit on ARC or Meta, although I'm not 100% sure about ino_t and nlink_t. This is all still true. You should have no syscall using 'off_t', only loff_t. I still don't know whether we would want 32 or 64 bit ino_t and nlink_t for new architectures. It seems it would gain very little, but have a noticeable overhead. Anyone have comment on this? Chung-Lin (in CC list) is our nios2 toolchain maintainer. Do you have any comment for 32 or 64 bit ino_t and nlink_t? We will update the toolchain to support 64-bit time_t, so we hope that any other toolchain change can happen in one time. For ino_t, 32-bit users of linux-generic glibc already use struct stat64, stat64(), etc. to align with 64-bit targets, so in terms of the glibc/kernel interface it doesn't matter much. The in-kernel usage of the ino_t type should be of more concern here. nlink_t appears to be always defined as u32 in linux/types.h, not sure if changing it to arch-overridable is reasonable. Chung-Lin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/28] nios2: Memory management
On 2014/4/22 下午 11:35, Ezequiel Garcia wrote: On Apr 22, Tobias Klauser wrote: On 2014-04-22 at 16:24:43 +0200, Ezequiel Garcia ezequiel.gar...@free-electrons.com wrote: Hi Ley Foon, On Apr 18, Ley Foon Tan wrote: +/* + * PAGE_SHIFT determines the page size + */ +#define PAGE_SHIFT12 +#define PAGE_SIZE 4096 +#define PAGE_MASK (~(PAGE_SIZE - 1)) + How about something like this: /* PAGE_SHIFT determines the page size */ #define PAGE_SHIFT 12 #define PAGE_SIZE (_AC(1,UL) PAGE_SHIFT) #define PAGE_MASK (~((1 PAGE_SHIFT) - 1)) Otherwise, the PAGE_SIZE macro above produces some warnings, IIRC. AFAIR old nios2 GCC versions (the 4.1 version from Windriver, IIRC) would complain about something like the above, that's the reason I added an explicit value for PAGE_SIZE back then. Other than being pretty the above fix is to remove a mismatch type warning. You can get rid of the warning in different ways: ifdef __ASSEMBLY__ define PAGE_SIZE 4096 else define PAGE_SIZE 4096UL endif I assume with the new nios2 GCC this should no longer be necessary and Ezequiel's fix should be fine. Speaking of GCC... is there a libc available to test this kernel port? (which I assume uses the generic syscall ABI) It's submitted to libc-alpha, also still review in progress. Chung-Lin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/28] nios2: Memory management
On 2014/4/23 上午 12:27, Ezequiel Garcia wrote: On Apr 23, Chung-Lin Tang wrote: On 2014/4/22 下午 11:35, Ezequiel Garcia wrote: On Apr 22, Tobias Klauser wrote: On 2014-04-22 at 16:24:43 +0200, Ezequiel Garcia ezequiel.gar...@free-electrons.com wrote: Hi Ley Foon, On Apr 18, Ley Foon Tan wrote: +/* + * PAGE_SHIFT determines the page size + */ +#define PAGE_SHIFT 12 +#define PAGE_SIZE 4096 +#define PAGE_MASK (~(PAGE_SIZE - 1)) + How about something like this: /* PAGE_SHIFT determines the page size */ #define PAGE_SHIFT 12 #define PAGE_SIZE (_AC(1,UL) PAGE_SHIFT) #define PAGE_MASK (~((1 PAGE_SHIFT) - 1)) Otherwise, the PAGE_SIZE macro above produces some warnings, IIRC. AFAIR old nios2 GCC versions (the 4.1 version from Windriver, IIRC) would complain about something like the above, that's the reason I added an explicit value for PAGE_SIZE back then. Other than being pretty the above fix is to remove a mismatch type warning. You can get rid of the warning in different ways: ifdef __ASSEMBLY__ define PAGE_SIZE 4096 else define PAGE_SIZE 4096UL endif I assume with the new nios2 GCC this should no longer be necessary and Ezequiel's fix should be fine. Speaking of GCC... is there a libc available to test this kernel port? (which I assume uses the generic syscall ABI) It's submitted to libc-alpha, also still review in progress. Do you plan to support uclibc? No, we (Mentor Graphics) are only doing glibc work at this point. Chung-Lin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 14/4/21 1:31 PM, H. Peter Anvin wrote: > On 04/20/2014 10:23 PM, Ley Foon Tan wrote: >> On Sat, Apr 19, 2014 at 11:30 PM, Arnd Bergmann wrote: >>> On Friday 18 April 2014, H. Peter Anvin wrote: Did the generic headers ever get updated to match Linus' guidance that any new architecture ports should use a 64-bit time_t? >>> >>> No, unfortunately not. With my rule that every architecture that gets >>> added needs to clean up asm-generic some more, to make it easier to add >>> the next one, we should probably do for nios2. >>> >>> Arnd >> >> Can you give me the documentation on this new guidance and point me >> any architecture have implemented this? >> Thanks. >> > > We implemented it in the x32 ABI for x86. In generic code this is keyed > by COMPAT_USE_64BIT_TIME, but in your case it isn't actually a matter of > compat, so it should be easier. > > See this thread including the discussion about time_t: > > https://lkml.org/lkml/2011/8/26/415 > > -hpa I'm not sure why we need CONFIG_USE_64BIT_TIME? We don't have any 32-on-64 problems. My understanding of what Arnd meant, was to clean up asm-generic/posix_types.h such that for example, time_t should be defined as a 'long long' type, which should be 64-bit almost everywhere. At least AFAIK, that should work for all current asm-generic users. Thanks, Chung-Lin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 14/4/21 1:31 PM, H. Peter Anvin wrote: On 04/20/2014 10:23 PM, Ley Foon Tan wrote: On Sat, Apr 19, 2014 at 11:30 PM, Arnd Bergmann a...@arndb.de wrote: On Friday 18 April 2014, H. Peter Anvin wrote: Did the generic headers ever get updated to match Linus' guidance that any new architecture ports should use a 64-bit time_t? No, unfortunately not. With my rule that every architecture that gets added needs to clean up asm-generic some more, to make it easier to add the next one, we should probably do for nios2. Arnd Can you give me the documentation on this new guidance and point me any architecture have implemented this? Thanks. We implemented it in the x32 ABI for x86. In generic code this is keyed by COMPAT_USE_64BIT_TIME, but in your case it isn't actually a matter of compat, so it should be easier. See this thread including the discussion about time_t: https://lkml.org/lkml/2011/8/26/415 -hpa I'm not sure why we need CONFIG_USE_64BIT_TIME? We don't have any 32-on-64 problems. My understanding of what Arnd meant, was to clean up asm-generic/posix_types.h such that for example, time_t should be defined as a 'long long' type, which should be 64-bit almost everywhere. At least AFAIK, that should work for all current asm-generic users. Thanks, Chung-Lin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
