[PATCH 2/2] Blackfin: Deal with flat binfmt differently to FDPICELF binfmt when dumping

From: Jie Zhang
Date: Thu Aug 16 2007 - 03:31:44 EST


This Blackfin arch patch uses the new `name' field in struct
linux_binfmt added by my first patch.


Jie


Signed-off-by: Jie Zhang <jie.zhang@xxxxxxxxxx>
---
arch/blackfin/kernel/traps.c | 16 ++++++++++++----
1 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/arch/blackfin/kernel/traps.c b/arch/blackfin/kernel/traps.c
index 792a841..9961c21 100644
--- a/arch/blackfin/kernel/traps.c
+++ b/arch/blackfin/kernel/traps.c
@@ -111,9 +111,7 @@ static int printk_address(unsigned long address)
/* FLAT does not have its text aligned to the start of
* the map while FDPIC ELF does ...
*/
- if (current->mm &&
- (address > current->mm->start_code) &&
- (address < current->mm->end_code))
+ if (strcmp(current->binfmt->name, "flat") == 0)
offset = address - current->mm->start_code;
else
offset = (address - vma->vm_start) + (vma->vm_pgoff << PAGE_SHIFT);
@@ -533,7 +531,7 @@ void dump_bfin_regs(struct pt_regs *fp, void *retaddr)
" or you are in the kernel\n");
}

- if (current->mm) {
+ if (current->mm && strcmp(current->binfmt->name, "flat") == 0) {
printk(KERN_EMERG "TEXT = 0x%p-0x%p DATA = 0x%p-0x%p\n"
KERN_EMERG "BSS = 0x%p-0x%p USER-STACK = 0x%p\n"
KERN_EMERG "\n",
@@ -544,6 +542,16 @@ void dump_bfin_regs(struct pt_regs *fp, void *retaddr)
(void *)current->mm->end_data,
(void *)current->mm->brk,
(void *)current->mm->start_stack);
+ } else if (current->mm
+ && strcmp(current->binfmt->name, "ELF FDPIC") == 0) {
+ printk(KERN_EMERG "TEXT = 0x%p-0x%p DATA = 0x%p-0x%p\n"
+ KERN_EMERG "USER-STACK = 0x%p\n"
+ KERN_EMERG "\n",
+ (void *)current->mm->start_code,
+ (void *)current->mm->end_code,
+ (void *)current->mm->start_data,
+ (void *)current->mm->end_data,
+ (void *)current->mm->start_stack);
}

printk(KERN_EMERG "return address: [0x%p]; contents of:", retaddr);
--
1.5.2.4
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/