Not that I'm actually involved any more, but I'd endorse the user_regset
approach and not the new request. On many (most?) machines, it's already
part of the main integer regset (orig_rax et al) and adding another
mechanism is redundant. Using user_regset also means there won't be a word
of hidde
That's OK with me. But I'm not really actively involved in kernel
maintenance any more (though happy to answer anything Oleg wants advice on).
Acked-By: Roland McGrath
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
> > config COMPAT_VDSO
> > def_bool y
> > prompt "Compat VDSO support"
> > depends on X86_32 || IA32_EMULATION
> > ---help---
> > Map the 32-bit VDSO to the predictable old-style address too.
> >
> > Say N here if you are running a sufficiently r
> I won't argue, but it is not clear to me if this is really useful,
> given that the debugger can read the regs.
I do see the utility of having a consistent machine-independent way to get
the syscall number from userspace. But note that this could be probably
accomplished with just a uapi header
The Kconfig text for COMPAT_VDSO suggests that glibc versions prior to
2.3.3 may have relied on the fixed address. I can't find anything in the
libc revision history to explain that (AFAIK the code always used
AT_SYSINFO* since it started using the vDSO at all), but it might have been
something le
There are other cases that just forward declare 'struct siginfo' and use it
instead of the typedef names (e.g. linux/sched.h).
--
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.
> > Again: has this proposal been reviewed by the glibc maintainers? If
> > so, what was their position on it?
>
> Ard have you talked with them? I would expect it would be welcomed.
> Roland, do you know who would be the right person to ask about this
> for glibc? (patch: https://lkml.org/lkml/2
The code needs to be macroized a bit so that compat_binfmt_elf.c will
produce a version that encodes 32-bit values correctly so as to be
compatible with the output of a native 32-bit kernel.
It's doubtful that rolling your own single loop actually performs better
than just calling strlen and memcp
> But, somehow I forgot about compat tasks when we discussed this before.
> Perhaps the code above should do
>
> if (is_compat_task())
> copy_siginfo_to_user32(...);
> else
> copy_siginfo_to_user(...);
>
> ?
compat_binfmt_elf.c will define a separate copy
Other ELF notes have per-machine layouts too. It's far more important to
reduce the total number of ways we have to represent the same information.
On a given machine, we already have a layout and we don't want another.
Debuggers and so forth already know how to handle the per-machine layouts.
The
I agree with Oleg. If there is an NT_SIGINFO note, it should contain
exactly the siginfo_t layout and data that we otherwise expose to userland
already. That is, it must match what PTRACE_GETSIGINFO reports, which (I
think) also matches exactly what appears on the stack for a signal
delivery. No
Thanks for the pointers, guys. It took a while for me to figure out what
got wrong to foul up UML, but the bug and fix are trivial (posting now).
Some of the testing I thought had got done clearly wasn't done, since
PTRACE_SETREGS was 100% busticated for 32-bit processes calling ptrace on
x86_64 k
Simple typo fix for regression introduced by the user_regset changes.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/kernel/ptrace.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 7
Sorry I haven't replied in this thread sooner.
I would like to see all the BTS and DS work wait until after 2.6.25.
We have a lot of x86 churn in 2.6.25 already, and I think we'd do
better without adding this wrinkle at the same time.
The low-level implementation pieces should gel a bit more in -
include/asm-x86/desc_64.h should have been removed, but is still in the
tree containing just a newline.
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-
> I've been looking at that, at the same time a bunch of ia32/signal.c
> looks like it can go away.
Yes, I meant the 3 into 1 unification.
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info a
> I spent some time read you mail carefully and dig into the code again.
>
> And yes, you are right. It's possible that SA_ONSTACK has been cleared
> before the second signal on the same stack comes.
It's not necessary for SA_ONSTACK to have "been cleared", by which I assume
you mean a sigaction
> You mean the comment?
No, that is trivial and already corrected. I mean the substance of your
most recent patch. I described why I think it is wrong. You did not respond.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
M
> > Please elaborate on the rationale that justifies this change.
> > I don't see it at all.
>
> I have corrected the comment in the latest patch which has been apllied by
> Ingo.
> Please refer to http://lkml.org/lkml/2008/2/18/575 and
> http://lkml.org/lkml/2008/2/19/119 .
You have yet to say
> These patches change the behaviour of programs that longjmp out of a
> signal handler on an alternate stack, don't they?
No, they don't. Shi Weihua's original patch had that problem.
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mes
> Shouldn't such programs use sigsetjmp/siglongjmp, which should reset the
> signal stack state?
That is not really related. The distinction doesn't really exist for
programs using the normal API (setjmp is sigsetjmp(,1)). What siglongjmp
guarantees handled is signal mask changes, not sigaltsta
This change looks bogus to me. Before I get to the content, there is a nit
that annoys me. You changed the punctuation in my comment so that it no
longer means what it did, and now the comment is nonsensical. I don't
demand decent English from hackers of any linguistic bent, but please don't
lou
> > > sed -n -e 's/^00*/0/' -e 's/^\([0-9a-fA-F]*\) . \(VDSO[a-zA-Z0-9_]*\)$/ =
> > > 0x;/p' | LC_ALL=C sort > arch/x86/vdso/vdso32-sysenter-syms.lds
> >
> > Also show me the vdso32-sysenter-syms.lds file.
>
> Attached.
The contents of this file are fine. If all the vdso32-*-syms.lds files
look
> I'm poking at it. Something in my cross compiling setup is driving this bit
> screwy:
>
> i686-nm arch/x86/vdso/vdso32-sysenter.so.dbg |
Show me the output of just this.
> sed -n -e 's/^00*/0/' -e 's/^\([0-9a-fA-F]*\) . \(VDSO[a-zA-Z0-9_]*\)$/ =
> 0x;/p' | LC_ALL=C sort > arch/x86/vdso/v
> Still trying to track down why, but it works on a toolchain built from
> binutils 2.18 and gcc 4.1.3, but not with a toolchain from binutils 2.17 and
> gcc 4.1.2. And considering where it's failing...
I don't think the vdso magic should require so new a binutils. Please try
to figure out whi
Perhaps it makes more sense to have vdso_install be a dependency of
modules_install rather than install, since they both put things in /lib/modules.
The installed vdso images are potentially useful for a kernel when you
aren't bothering to build or install any modules, but those images are only
eve
I don't have any axe to grind here, I just could not figure out how to get
the samples/ modules built (without resorting to make M=.../samples/foo and
clobbering my source directory). If there is another plan, point me to its
documentation. I can't see the point of the Kconfig option for samples
> Sam, is this ok with the samples intent ? I think as long as we do not
> include them with the kernel image and have a "make samples" to build
> them, it's ok. Having them built upon make modules seems like a good
> idea to me.
I"m not sure what you mean by "with the kernel image".
AFAICT, eve
of the directory use core-$(CONFIG_SAMPLES)
because there is no other conditional like that in the top-level Makefile
and samples/Makefile already uses obj-$(CONFIG_SAMPLES) as if it expects
always to be included.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
Makefile |5 +
1 fi
Good change. Making it global was needed temporarily in between some of
the i387 unification patches, but is unnecessary after the final merge.
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
> You silently overwrite any user ptrace hw breakpoints right? To do it cleanly
> would still require a reservation frame work.
There was work underway on that before (hw_breakpoint). I'm not entirely
sure you want to use fancy stuff like that in kgdb. It's nice for kgdb to
be as self-contained
>
> * Roland McGrath <[EMAIL PROTECTED]> wrote:
>
> > > LD init/built-in.o
> > > distcc[12023] ERROR: compile (null) on localhost failed
> > > make: *** [vmlinux.o] Error 1
> >
> > That message sure looks to me like it could only
> LD init/built-in.o
> distcc[12023] ERROR: compile (null) on localhost failed
> make: *** [vmlinux.o] Error 1
That message sure looks to me like it could only be a distcc bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROT
I did not see it with your .config either.
> This fails with clean build. And vdso-syms.lds is not empty.
>
> Contents of ?arch/x86/vdso/vdso-syms.lds:
> VDSO64_PRELINK = 0xff70;
> VDSO64_jiffies = 0xff7004b8;
Odd. The missing symbols come from the same place that VDSO64_jif
Sam might want to experiment with something like:
stdout_target = $(1) > $(@D)/.tmp_$(@F) && mv -f $(@D)/.tmp_$(@F) $@
cmd_foo = $(call stdout_target,blah | sed s/foo/bar/)
to clean up all the places that would benefit from robust treatment for
output files vs interrupted/erring
> if that file is empty, it might be the effect of a Ctrl-C. I sometimes
> get that on .o files, if i Ctrl-C a highly parallel make -j at the wrong
> moment. (is this expected behavior? It's been like this for a long
> time.)
It is the known situation with the compiler since the dawn of time, y
I was not able to reproduce this failure. Those symbols should be defined
by arch/x86/vdso/vdso-syms.lds, a file generated by the build. If that
file is empty in your build, remove it and see if it gets regenerated
properly, or try a clean build. If the problem persists, please send me
your comp
The makefile magic for installing the 32-bit vdso images on disk
had a little error. Only one line of change would fix that bug.
This does a little more to reduce the error-prone duplication of
this bit of makefile variable magic.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
ar
It sure didn't look to me like paravirt probably worked. But what do I know?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://ww
> Did you test without CONFIG_PARAVIRT, and CONFIG_PARAVIRT booted both with and
> without the "noreplace-paravirt" parameter?
I did not test CONFIG_PARAVIRT at all. I just fixed what its introduction
had done to break generic x86-64.
Thanks,
Roland
--
To unsubscribe from this list: send the li
> thanks, applied. I suppose you have a testcase for this that we could try?
This should exit 0 and show "wait status 0xb7f", and does on i386.
On 2.6.24 it exits 1 and shows "wait status 0xb".
Note, on the current tree before [PATCH] x86_64: fix iret exception recovery
that I also posted today,
> > thanks, applied. I suppose you have a testcase for this that we could try?
>
> This should exit 0 and show "wait status 0xb7f", and does on i386.
> On 2.6.24 it exits 1 and shows "wait status 0xb".
To clarify, build the case with -m32 but run on x86_64.
Thanks,
Roland
--
To unsubscribe from
Date: Fri Apr 29 09:38:44 2005 -0700
x86: make traps on 'iret' be debuggable in user space
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/kernel/entry_64.S | 25 +++--
1 files changed, 19 insertions(+), 6 deletions(-)
diff -
hat use, anyone exercising
the minimum of attention to detail expected of anyone touching this
subtle code would realize it needed to change as well.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/kernel/entry_64.S |3 +--
1 files changed, 1 insertions(+), 2 deletions(
subtlety from being overlooked again.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/kernel/ptrace.c | 25 +++--
1 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 96286df..702c33e
Sorry I did not get more into this discussion earlier. I still have not
read through all of the email threads. But I have looked over the current
version of your code now in -mm.
I think this work has a great deal of overlap with the perfmon2 project.
There are two facets that overlap, which tog
> On Thu, Jan 24, 2008 at 05:59:33PM -0800, Roland McGrath wrote:
> > + if (pos > 0 || count < sizeof(env))
> > + convert_from_fxsr(&env, target);
>
> Well, is the generic regset code enforce the need for this now? Can we
> disallow the usage cases wh
: Suresh Siddha <[EMAIL PROTECTED]>
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/kernel/i387.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index 7e354a3..26719bd 100644
--- a/arch/x86/k
I agree that RUSAGE_THREAD is fine. (In fact, if you'd pressed me to
remember without looking, I would have assumed we put it in already.)
However, in the implementation, I would keep it cleaner by moving the
identical code from inside the loop under case RUSAGE_SELF into a shared
subfunction, rat
This adds the RUSAGE_THREAD option for the getrusage system call.
Solaris calls this RUSAGE_LWP and uses the same value (1).
That name is not a natural one for Linux, but we keep it as an alias.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
include/linux/resource.h |2 ++
Oops, I overlooked the use of elf_core_copy_regs in kernel/kexec.c. It
is certainly safe and fine to reintroduce the old macro. Everything
removed in the "x86 user_regset cleanup" patch is purely removing code
and it doesn't hurt to have it back (it's just all unused except for this
kexec nit).
It's indeed true that &pt_regs is truly the esp value for x86-32
kernel-mode trap frames. Because this nonobvious calculation is
only right for a kernel mode pt_regs and not for a user-mode one,
I think it would be better to use a name for the inline/macro that
makes this quite clear, rather than
This preserves the parts of my change that mattered, is correctly more
conservative than my change was, and is fine with me.
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.k
> thanks, applied. Does this explain the crash/hang problems with 32-bit
> apps on 64-bit kernels? What was the exact failure mode?
It does. Any 32-bit process trying to run a signal handler when it had
used the FPU, would clobber "current" with FP bits. The observed failure
mode was shortly af
Sorry about this one, mea culpa. This should go right after
the "x86 i387 user_regset" patch, or be rolled into it.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/ia32/ia32_signal.c |5 ++---
arch/x86/kernel/ptrace.c|1 -
include/asm-x86/fp
I bisected my startup problem down to:
197e4989b0404996dfe3ab091c1398e4c2813d44 is first bad commit
commit 197e4989b0404996dfe3ab091c1398e4c2813d44
Author: Ingo Molnar <[EMAIL PROTECTED]>
Date: Wed Jan 9 13:31:06 2008 +0100
x86: mark native_read_tsc()
Probably true that it's not worth the space. I couldn't figure a way to do
it that doesn't use at least 8 bytes per vector. Of course, the vectors
>= 32 are never interesting, so 256 bytes of dispatch table could cover it.
Anyway, I think it's fine just to have the patch on hand to enable for a
It's not too pretty, but I found this made the "PANIC: early exception"
messages become much more reliably useful: 1. print the vector number,
2. print the %cs value, 3. handle error-code-pushing vs non-pushing vectors.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
a
gid of the real_parent, not its pid.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
fs/proc/array.c |4 ++--
include/linux/sched.h | 13 -
kernel/timer.c|2 +-
3 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/fs/proc/array.c b/fs/pr
I agree with your points. I thought about making it display both.
But I didn't want to worry about breaking scripts that parse console
logs or whatever. Personally I don't think I've ever found the ppid
in that display useful in debugging a ptrace issue. I don't have any
special opinions about t
The show_task function invoked by sysrq-t et al displays the
pid and parent's pid of each task. It seems more useful to
show the actual process hierarchy here than who is using
ptrace on each process.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
kernel/sched.c |2
The ac_ppid field reported in process accounting records
should match what getppid() would have returned to that
process, regardless of whether a debugger is attached.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
kernel/acct.c |2 +-
1 files changed, 1 insertions(+), 1 del
The pr_ppid field reported in core dumps should match what
getppid() would have returned to that process, regardless of
whether a debugger is attached.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
fs/binfmt_elf.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff
-mode
threads' registers for debugging and dumping.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ptrace.c | 162 ++
1 files changed, 162 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/a
I have no opinions about the config symbol names. Among the existing
precedents for internal/descriptionless symbols I find more not using the
HAVE_ prefix than those using it. The patch versions I've sent now work
fine, fix the parallel build problem people were seeing, and AFAICT follow
the sty
e macro we have to
define to make the generic support work out of the box.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig |1 +
arch/powerpc/kernel/Makefile |2 +-
arch/powerpc/kernel/binfmt_elf32.c | 69 -
This patch replaces the earlier patch by the same title already in x86/mm:
commit a9014d2dfcb253fb3ce5f4e3318849f743b85427
Author: Roland McGrath <[EMAIL PROTECTED]>
x86 compat_binfmt_elf
It requires the new patch I just posted, titled "compat_binfmt_
This patch should go in immediately after:
commit 5e45efc63e33ee2bae9ff4d500b53d3bf86d2b48
Author: Roland McGrath <[EMAIL PROTECTED]>
compat_binfmt_elf
Thanks,
Roland
---
[PATCH] compat_binfmt_elf Kconfig
This adds Kconfig and Makefile bits to bu
The __GLIBC__ uses look like:
#if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2)
That block does not affect any extant glibc, so we don't care if you remove
those conditions. Any non-glibc users of thes headers might care, since
they are the ones affected.
TGhe __USE_ALL
I'd make those *.lds or at least vdso*.lds, since it is more likely there
will be other variants than that there will be any .lds source files (since
they are .lds.S instead).
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EM
> On Thu, Dec 20, 2007 at 03:58:16AM -0800, Roland McGrath wrote:
> > +obj-$(CONFIG_PPC64)+= ../../../fs/compat_binfmt_elf.o
>
> Building files from another directory is nasty. Please add a
> CONFIG_BINFMT_COMPAT_ELF so we can simply build it in fs/
If that
> Nice, we should have unified the compat ptrace code long ago.
There is still more consolidation that can be done, but this is a first step.
> Any chance you could make the ifdef symetric to the native ptrace
> where an arch defines a symbol if it has it's own ptrace?
That would require touchin
> What's a Red Hat Author? Sorry for the nitpicking, but why don't you
> just use Author like everyone else?
This text is the standard that my employer specifies.
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTEC
.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
arch/x86/kernel/ptrace.c |1 +
include/linux/elf.h |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git
This removes duplicated code by calling the generic ptrace_request and
compat_ptrace_request functions for the things they already handle.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/kernel/ptrace.c | 37 +
1 files changed, 1 inse
This adds hard-wired definitions for the remaining cpu_has_* macros
that correspond to flags required-features.h demands are set for
64-bit. Using these can efficiently avoid some #ifdef's when
merging 32-bit and 64-bit code together.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
This extends task_user_regset_view CONFIG_PPC64 with support for the 32-bit
view of register state, compatible with what a CONFIG_PPC32 kernel provides.
This will enable generic machine-independent code to access user-mode
threads' registers for debugging and dumping.
Signed-off-by: R
restore_i387, which is
already an inline, and makes sense since there is exactly one
caller (in signal_64.c). The save_i387 function could use more
cosmetic cleanup, but it is just moved verbatim in this patch.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL
Now that ptrace_request handles these, we can drop some more boilerplate.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ptrace.c | 12
1 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/
: Roland McGrath <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/Makefile |3 +-
arch/powerpc/kernel/binfmt_elf32.c | 69
include/asm-powerpc/elf.h |1 +
3 files changed, 3 insertions(+), 70 deletions(-)
diff --git a/arch/powerpc/kernel/Ma
This adds accessor functions in the user_regset style for
the general registers (struct user_regs_struct).
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
arch/x86/kern
This adds accessor functions in the user_regset style for the TLS data.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
arch/x86/k
This defines task_user_regset_view and the tables
describing the x86 user_regset layouts for 32 and 64.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
arch/x86/kern
This provides the task_user_regset_view entry point and support for all the
native-mode (64 on CONFIG_PPC64, 32 on CONFIG_PPC32) thread register state.
This will enable generic machine-independent code to access user-mode
threads' registers for debugging and dumping.
Signed-off-by: Roland Mc
This cleans up the TLS code to use struct desc_struct and to separate the
encoding and installation magic from the interface wrappers.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]
This converts the ptrace/signal accessors for i387 math_emu
state to the user_regset interface style, and calls these
from the old interfaces.
It also cleans up math_emulate's ptrace check to be a
single-step check, which is what it really wants.
Signed-off-by: Roland McGrath <[EMAIL P
x27;s what took the
least cleanup in each file. Here i387.h is stubbed to always
include i387_64.h rather than renaming the file, to keep this
diff smaller and easier to read.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by
n the
amount of #ifdef hair required throughout the i387 code.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
include/asm-x86/processor.h | 92 +++-
This switches x86-64's 32-bit ELF support to use the shared
fs/compat_binfmt_elf.c code instead of our own ia32_binfmt.c.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
Remove the old ia32_binfmt.c file, which is no longer used.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
arch/x86/ia32/ia32_binfmt.c | 284
This removes all the old code that is no longer used after
the i387 unification and cleanup. The i387_64.h is renamed
to i387.h with no changes, but since it replaces the nonempty
one-line stub i387.h it looks like a big diff and not a rename.
Signed-off-by: Roland McGrath <[EMAIL PROTEC
This implements user_regset-style accessors for the powerpc SPE data,
and rewrites the existing ptrace code in terms of those calls.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ptrace.c | 90 ++---
1 files changed, 57 inse
This removes a bunch of dead code that is no longer needed now
that the user_regset interfaces are being used for all these jobs.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]
This cleans up the PTRACE_*REGS* request code so each one is just a
simple call to copy_regset_to_user or copy_regset_from_user. The
ptrace layouts already match the user_regset formats (core dump formats).
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar &
This implements user_regset-style accessors for the powerpc FPU data,
and rewrites the existing ptrace code in terms of those calls.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ptrace.c | 37 +++--
1 files changed, 31 inse
This renames arch/x86/kernel/{i387_32.c => i387.c}.
This is a pure renaming, but paves the way for merging
the 32-bit and 64-bit versions of this code.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner &l
This cleans up the 32-bit ptrace syscall support to use user_regset calls
to get at the register data for PTRACE_*REGS* calls.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ptrace32.c | 96 ++-
1 files changed, 25 inse
This switches x86 to the user_regset-based code for ELF core dumps.
The core dumps come out exactly the same as before.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
inc
This implements user_regset-style accessors for the powerpc Altivec data,
and rewrites the existing ptrace code in terms of those calls.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ptrace.c | 112 +-
1 files chang
This removes some duplicated code by calling the new generic
compat_ptrace_request from powerpc's compat_sys_ptrace.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ptrace32.c | 34 ++
1 files changed, 2 insertions(+), 3
1 - 100 of 533 matches
Mail list logo
