All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <dan@debian.org>
To: "David S. Miller" <davem@davemloft.net>
Cc: linux-kernel@vger.kernel.org
Subject: Contents of core dumps (was: Re: fs/binfmt_elf.c:maydump())
Date: Tue, 2 Jan 2007 21:02:28 -0500	[thread overview]
Message-ID: <20070103020228.GA28762@nevyn.them.org> (raw)
In-Reply-To: <20060406.221807.114721185.davem@davemloft.net>

[Please CC, I am not subscribed to lkml.]

On Thu, Apr 06, 2006 at 10:18:07PM -0700, David S. Miller wrote:
> How about something like the following patch?  If it's executable
> and not written to, skip it.  This would skip the main executable
> image and all text segments of the shared libraries mapped in.

I've been going through GDB test failures (... again...) and I'm down
to a respectably small number on x86_64, but this is one of the
remaining ones.  I don't suppose there's been any change since we
discussed this in April?

A refresher for those following along: there's a GDB test that mmaps a
file using MAP_PRIVATE and PROT_WRITE.  It expects the contents to end
up in the core dump.  Right now, they don't.  I can fix the test by
making sure it writes to the mapping, but before I change the test,
I want to raise the question of what _should_ be in a core dump.

I took a peek at what Solaris includes in core dumps.  They offer
(not surprisingly) a pile of configuration options.  The default is
just about everything except for file-backed shared memory and some
symbol table data - it includes text segments, rodata, anonymous shared
memory, file backed mappings, et cetera.  I guess that's another
argument in favor of dumping more.  Then you can control it globally,
per process, et cetera.

http://src.opensolaris.org/source/xref/loficc/crypto/usr/src/uts/common/sys/corectl.h

I also checked an AIX manual since there was a reference to SA_FULLDUMP
in the GDB test:

 By default, the user data, anonymously mapped regions, and vm_infox
 structures are not included in a core dump. This partial core dump
 includes the current thread stack, the thread thrdctx structures, the
 user structure, and the state of the registers at the time of the
 fault. A partial core dump contains sufficient information for a stack
 traceback. The size of a core dump can also be limited by the setrlimit
 or setrlimit64 subroutine.

 To enable a full core dump, set the SA_FULLDUMP flag in the sigaction
 subroutine for the signal that is to generate a full core dump. If this
 flag is set when the core is dumped, the user data section, vm_infox,
 and anonymously mapped region structures are included in the core dump.

Not really sure what that translates to, but it's less than what
Solaris dumps, I think.

Does Linux need knobs for this?

> 
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 537893a..9ec5c2b 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -1167,8 +1167,10 @@ static int maydump(struct vm_area_struct
>  	if (vma->vm_flags & VM_SHARED)
>  		return vma->vm_file->f_dentry->d_inode->i_nlink == 0;
>  
> -	/* If it hasn't been written to, don't write it out */
> -	if (!vma->anon_vma)
> +	/* If it is executable and hasn't been written to,
> +	 * don't write it out.
> +	 */
> +	if ((vma->vm_flags & VM_EXEC) && !vma->anon_vma)
>  		return 0;
>  
>  	return 1;
> 
> 

-- 
Daniel Jacobowitz
CodeSourcery

  parent reply	other threads:[~2007-01-03  2:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-06 21:03 fs/binfmt_elf.c:maydump() David S. Miller
2006-04-06 22:15 ` fs/binfmt_elf.c:maydump() Daniel Jacobowitz
2006-04-06 22:35   ` fs/binfmt_elf.c:maydump() David S. Miller
2006-04-07  5:18     ` fs/binfmt_elf.c:maydump() David S. Miller
2006-04-07 18:02       ` fs/binfmt_elf.c:maydump() Daniel Jacobowitz
2006-04-07 20:27         ` fs/binfmt_elf.c:maydump() David S. Miller
2006-04-10 13:01           ` fs/binfmt_elf.c:maydump() Daniel Jacobowitz
2007-01-03  2:02       ` Daniel Jacobowitz [this message]
2007-01-03  4:57         ` Contents of core dumps David Miller
2007-01-03 18:13           ` Daniel Jacobowitz

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=20070103020228.GA28762@nevyn.them.org \
    --to=dan@debian.org \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    /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.