All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Daney <ddaney@caviumnetworks.com>
To: Yong Zhang <yong.zhang@windriver.com>
Cc: linux-kernel@vger.kernel.org, ralf@linux-mips.org,
	linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH] MIPS: o32 application running on 64bit kernel core dump
Date: Wed, 01 Jul 2009 12:09:10 -0700	[thread overview]
Message-ID: <4A4BB456.9090404@caviumnetworks.com> (raw)
In-Reply-To: <16bd35f2910f585740f4764fa1e80bf31c80d576.1242178813.git.yong.zhang@windriver.com>

Yong Zhang wrote:
> If an o32 application crashes and generates a core dump on
> a 64 bit kernel, the core file will not be correctly
> recognized. This is because ELF_CORE_COPY_REGS and
> ELF_CORE_COPY_TASK_REGS are not correctly defined for o32
> and will use the default register set which would
> be CONFIG_64BIT in asm/elf.h.
> 
> So we'll switch to use the right register defines in
> this situation by checking for WANT_COMPAT_REG_H and
> use the right defines of ELF_CORE_COPY_REGS and
> ELF_CORE_COPY_TASK_REGS.

This patch looks plausible.  How was it tested?

Can you still obtain good core files with at 32-bit kernel?

Are usable core files obtained for all three ABIs on 64-bit kernels?

Other than that, I have only the one comment below.

Thanks,
David Daney


> 
> Signed-off-by: Yong Zhang <yong.zhang@windriver.com>
> ---
>  arch/mips/include/asm/elf.h      |    4 ++++
>  arch/mips/include/asm/reg.h      |    2 +-
>  arch/mips/kernel/binfmt_elfo32.c |   20 +++++++++++++++++---
>  3 files changed, 22 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/mips/include/asm/elf.h b/arch/mips/include/asm/elf.h
> index d58f128..7990694 100644
> --- a/arch/mips/include/asm/elf.h
> +++ b/arch/mips/include/asm/elf.h
> @@ -316,9 +316,13 @@ extern void elf_dump_regs(elf_greg_t *, struct pt_regs *regs);
>  extern int dump_task_regs(struct task_struct *, elf_gregset_t *);
>  extern int dump_task_fpu(struct task_struct *, elf_fpregset_t *);
>  
> +#ifndef ELF_CORE_COPY_REGS
>  #define ELF_CORE_COPY_REGS(elf_regs, regs)			\
>  	elf_dump_regs((elf_greg_t *)&(elf_regs), regs);
> +#endif
> +#ifndef ELF_CORE_COPY_TASK_REGS
>  #define ELF_CORE_COPY_TASK_REGS(tsk, elf_regs) dump_task_regs(tsk, elf_regs)
> +#endif
>  #define ELF_CORE_COPY_FPREGS(tsk, elf_fpregs)			\
>  	dump_task_fpu(tsk, elf_fpregs)
>  
> diff --git a/arch/mips/include/asm/reg.h b/arch/mips/include/asm/reg.h
> index 634b55d..910e71a 100644
> --- a/arch/mips/include/asm/reg.h
> +++ b/arch/mips/include/asm/reg.h
> @@ -69,7 +69,7 @@
>  
>  #endif
>  
> -#ifdef CONFIG_64BIT
> +#if defined(CONFIG_64BIT) && !defined(WANT_COMPAT_REG_H)
>  
>  #define EF_R0			 0
>  #define EF_R1			 1
> diff --git a/arch/mips/kernel/binfmt_elfo32.c b/arch/mips/kernel/binfmt_elfo32.c
> index e1333d7..53bc6b4 100644
> --- a/arch/mips/kernel/binfmt_elfo32.c
> +++ b/arch/mips/kernel/binfmt_elfo32.c
> @@ -53,6 +53,23 @@ typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
>  #define ELF_ET_DYN_BASE         (TASK32_SIZE / 3 * 2)
>  
>  #include <asm/processor.h>
> +
> +/*
> + * When this file is selected, we are definitely running a 64bit kernel.
> + * So using the right regs define in asm/reg.h
> + */
> +#define WANT_COMPAT_REG_H
> +
> +/* These MUST be defined before elf.h gets included */
> +extern void elf32_core_copy_regs(elf_gregset_t grp, struct pt_regs *regs);
> +#define ELF_CORE_COPY_REGS(_dest, _regs) elf32_core_copy_regs(_dest, _regs);
> +#define ELF_CORE_COPY_TASK_REGS(_tsk, _dest)				\
> +({									\
> +	int __res = 1;							\
> +	elf32_core_copy_regs((*_dest), (task_pt_regs(_tsk)));		\
> +	__res;								\

Why does __res exist?  Can't you have that last line just be '1;'?

> +})
> +
>  #include <linux/module.h>
>  #include <linux/elfcore.h>
>  #include <linux/compat.h>
> @@ -110,9 +127,6 @@ jiffies_to_compat_timeval(unsigned long jiffies, struct compat_timeval *value)
>  	value->tv_usec = rem / NSEC_PER_USEC;
>  }
>  
> -#undef ELF_CORE_COPY_REGS
> -#define ELF_CORE_COPY_REGS(_dest, _regs) elf32_core_copy_regs(_dest, _regs);
> -
>  void elf32_core_copy_regs(elf_gregset_t grp, struct pt_regs *regs)
>  {
>  	int i;

  reply	other threads:[~2009-07-01 19:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-14  3:15 [PATCH] MIPS: o32 application running on 64bit kernel core dump Yong Zhang
2009-07-01  1:35 ` Yong Zhang
2009-07-01 19:09 ` David Daney [this message]
2009-07-02  1:25   ` Yong Zhang
2009-07-01 19:19 ` Ralf Baechle
2009-07-01 23:47 ` Ralf Baechle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A4BB456.9090404@caviumnetworks.com \
    --to=ddaney@caviumnetworks.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=yong.zhang@windriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.