2005-04-16 22:20:36 +00:00
|
|
|
#
|
|
|
|
|
# Makefile for the linux kernel.
|
|
|
|
|
#
|
|
|
|
|
|
2006-01-03 17:28:33 +00:00
|
|
|
AFLAGS_head.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
# Object file lists.
|
|
|
|
|
|
2006-01-04 15:44:16 +00:00
|
|
|
obj-y := compat.o entry-armv.o entry-common.o irq.o \
|
2007-04-28 08:59:37 +00:00
|
|
|
process.o ptrace.o semaphore.o setup.o signal.o \
|
|
|
|
|
sys_arm.o stacktrace.o time.o traps.o
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2006-01-04 15:44:16 +00:00
|
|
|
obj-$(CONFIG_ISA_DMA_API) += dma.o
|
2005-04-16 22:20:36 +00:00
|
|
|
obj-$(CONFIG_ARCH_ACORN) += ecard.o
|
|
|
|
|
obj-$(CONFIG_FIQ) += fiq.o
|
|
|
|
|
obj-$(CONFIG_MODULES) += armksyms.o module.o
|
|
|
|
|
obj-$(CONFIG_ARTHUR) += arthur.o
|
|
|
|
|
obj-$(CONFIG_ISA_DMA) += dma-isa.o
|
2006-08-28 11:47:05 +00:00
|
|
|
obj-$(CONFIG_PCI) += bios32.o isa.o
|
2005-04-16 22:20:36 +00:00
|
|
|
obj-$(CONFIG_SMP) += smp.o
|
2007-02-06 20:29:00 +00:00
|
|
|
obj-$(CONFIG_KEXEC) += machine_kexec.o relocate_kernel.o
|
ARM kprobes: instruction single-stepping support
This is the code implementing instruction single-stepping for kprobes
on ARM.
To get around the limitation of no Next-PC and no hardware single-
stepping, all kprobe'd instructions are split into three camps:
simulation, emulation, and rejected. "Simulated" instructions are
those instructions which behavior is reproduced by straight C code.
"Emulated" instructions are ones that are copied, slightly altered
and executed directly in the instruction slot to reproduce their
behavior. "Rejected" instructions are ones that could be simulated,
but work hasn't been put into simulating them. These instructions
should be very rare, if not unencountered, in the kernel. If ever
needed, code could be added to simulate them.
One might wonder why this and the ptrace singlestep facility are not
sharing some code. Both approaches are fundamentally different because
the ptrace code regains control after the stepped instruction by installing
a breakpoint after the instruction itself, and possibly at the location
where the instruction might be branching to, instead of simulating or
emulating the target instruction.
The ptrace approach isn't suitable for kprobes because the breakpoints
would have to be moved back, and the icache flushed, everytime the
probe is hit to let normal code execution resume, which would have a
significant performance impact. It is also racy on SMP since another
CPU could, with the right timing, sail through the probe point without
being caught. Because ptrace single-stepping always result in a
different process to be scheduled, the concern for performance is much
less significant.
On the other hand, the kprobes approach isn't (currently) suitable for
ptrace because it has no provision for proper user space memory
protection and translation, and even if that was implemented, the gain
wouldn't be worth the added complexity in the ptrace path compared to
the current approach.
So, until kprobes does support user space, both kprobes and ptrace are
best kept independent and separate.
Signed-off-by: Quentin Barnes <qbarnes@gmail.com>
Signed-off-by: Abhishek Sagar <sagar.abhishek@gmail.com>
Signed-off-by: Nicolas Pitre <nico@marvell.com>
2007-06-11 22:20:10 +00:00
|
|
|
obj-$(CONFIG_KPROBES) += kprobes-decode.o
|
2006-01-14 16:35:31 +00:00
|
|
|
obj-$(CONFIG_OABI_COMPAT) += sys_oabi-compat.o
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2006-06-27 22:03:03 +00:00
|
|
|
obj-$(CONFIG_CRUNCH) += crunch.o crunch-bits.o
|
|
|
|
|
AFLAGS_crunch-bits.o := -Wa,-mcpu=ep9312
|
|
|
|
|
|
[ARM] 3881/4: xscale: clean up cp0/cp1 handling
XScale cores either have a DSP coprocessor (which contains a single
40 bit accumulator register), or an iWMMXt coprocessor (which contains
eight 64 bit registers.)
Because of the small amount of state in the DSP coprocessor, access to
the DSP coprocessor (CP0) is always enabled, and DSP context switching
is done unconditionally on every task switch. Access to the iWMMXt
coprocessor (CP0/CP1) is enabled only when an iWMMXt instruction is
first issued, and iWMMXt context switching is done lazily.
CONFIG_IWMMXT is supposed to mean 'the cpu we will be running on will
have iWMMXt support', but boards are supposed to select this config
symbol by hand, and at least one pxa27x board doesn't get this right,
so on that board, proc-xscale.S will incorrectly assume that we have a
DSP coprocessor, enable CP0 on boot, and we will then only save the
first iWMMXt register (wR0) on context switches, which is Bad.
This patch redefines CONFIG_IWMMXT as 'the cpu we will be running on
might have iWMMXt support, and we will enable iWMMXt context switching
if it does.' This means that with this patch, running a CONFIG_IWMMXT=n
kernel on an iWMMXt-capable CPU will no longer potentially corrupt iWMMXt
state over context switches, and running a CONFIG_IWMMXT=y kernel on a
non-iWMMXt capable CPU will still do DSP context save/restore.
These changes should make iWMMXt work on PXA3xx, and as a side effect,
enable proper acc0 save/restore on non-iWMMXt capable xsc3 cores such
as IOP13xx and IXP23xx (which will not have CONFIG_CPU_XSCALE defined),
as well as setting and using HWCAP_IWMMXT properly.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2006-12-03 17:51:14 +00:00
|
|
|
obj-$(CONFIG_CPU_XSCALE) += xscale-cp0.o
|
|
|
|
|
obj-$(CONFIG_CPU_XSC3) += xscale-cp0.o
|
|
|
|
|
obj-$(CONFIG_IWMMXT) += iwmmxt.o
|
2005-04-16 22:20:36 +00:00
|
|
|
AFLAGS_iwmmxt.o := -Wa,-mcpu=iwmmxt
|
|
|
|
|
|
|
|
|
|
ifneq ($(CONFIG_ARCH_EBSA110),y)
|
|
|
|
|
obj-y += io.o
|
|
|
|
|
endif
|
|
|
|
|
|
2006-04-24 08:45:35 +00:00
|
|
|
head-y := head$(MMUEXT).o
|
2005-04-16 22:20:36 +00:00
|
|
|
obj-$(CONFIG_DEBUG_LL) += debug.o
|
|
|
|
|
|
|
|
|
|
extra-y := $(head-y) init_task.o vmlinux.lds
|