From: Pedro Alves <palves@redhat.com>
To: Anshuman Khandual <khandual@linux.vnet.ibm.com>, viro@zeniv.linux.org.uk
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] elf, coredump: Extract only the active register set during core dump
Date: Tue, 27 May 2014 18:44:04 +0100 [thread overview]
Message-ID: <5384CEE4.10300@redhat.com> (raw)
In-Reply-To: <1400822213-18004-1-git-send-email-khandual@linux.vnet.ibm.com>
On 05/23/2014 06:16 AM, Anshuman Khandual wrote:
> Regset active hooks provide a way to query how many registers in the
> register set are active at any point of time. Currently this information
> is being ignored while creating core dump sections corresponding to any
> core note register set. This way the core dump will contain data which are
> not part of the active context of the process and may not be useful. This
> patch will make sure that only the active part of the register set are
> captured during the core dump process which will reduce the core dump
> size.
>
> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
> ---
> NOTE:
> Pedro Alves has mentioned that producing smaller note sections in the core
> dump may break some existing consumers. I request suggestions, reviews and
> test reports on different architectures to prove that this patch does not
> break any existing consumer. Thank you.
Yeah, FYI, I mentioned that after noticing that ia64 does:
mainline/linux-2.6/arch/ia64/kernel/ptrace.c:
static int
fpregs_active(struct task_struct *target, const struct user_regset *regset)
{
return (target->thread.flags & IA64_THREAD_FPH_VALID) ? 128 : 32;
}
And it's likely that tools expect fpregset_t to have a fixed size.
include/uapi/linux/elfcore.h:
22 typedef elf_fpregset_t fpregset_t;
arch/ia64/include/asm/elf.h:
186 typedef struct ia64_fpreg elf_fpreg_t;
187 typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
arch/ia64/include/asm/elf.h:
154 #define ELF_NGREG 128 /* we really need just 72 but let's leave some headroom... */
155 #define ELF_NFPREG 128 /* f0 and f1 could be omitted, but so what... */
I haven't done an exhaustive look over ports.
--
Pedro Alves
prev parent reply other threads:[~2014-05-27 17:44 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-23 5:16 [PATCH] elf, coredump: Extract only the active register set during core dump Anshuman Khandual
2014-05-27 17:44 ` Pedro Alves [this message]
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=5384CEE4.10300@redhat.com \
--to=palves@redhat.com \
--cc=khandual@linux.vnet.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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.