This is the mail archive of the
mailing list for the GDB project.
Re: [RFA] New "generate-core-file" command, supercedes previous
- From: Michael Snyder <msnyder at redhat dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: Michael Snyder <msnyder at cygnus dot com>, gdb-patches at sources dot redhat dot com, cagney at redhat dot com, kettenis at science dot uva dot nl, kevinb at redhat dot com, orjan dot friberg at axis dot com
- Date: Fri, 04 Jan 2002 12:17:00 -0800
- Subject: Re: [RFA] New "generate-core-file" command, supercedes previous
- Organization: Red Hat, Inc.
- References: <email@example.com> <20020104140453.A26863@nevyn.them.org>
Daniel Jacobowitz wrote:
> On Thu, Jan 03, 2002 at 05:51:51PM -0800, Michael Snyder wrote:
> > OK, this submission supercedes the previous one for the gcore command.
> > The command is now called "generate-core-files", with gcore as an alias.
> > This patch can now generate multi-threaded corefiles both on solaris
> > and on linux. The host makefile fragments for sparc-solaris and for
> > i386-linux have been updated to bring in the new code. The new code
> > will not affect any other targets until their makefile fragmemts are
> > modified to pull it in. It should work as-is for any flavor of
> > Solaris or Linux, but I've only tested sparc and i386 respectively.
> > As before, there is a patch for bfd appended, which has not yet
> > been approved by the bfd/binutils maintainers.
> > I'm now ready to formally request approval -- though there's still
> > room for improvement, I believe it's mature enough to check in.
> It looks solid to me. I especially like the supporting multiple
> threads bit.
> For future consideration, it would be -very- nice if this supported
> writing sparse files. That will, of course, require a BFD change.
> Right now, the dump for a 12-threaded application is about 25MB virtual
> size and no more than 1MB physical on-disk size, because the stacks for
> each thread are a 2MB sparse region.
Yes, Andrew and I have discussed that a bit. Definitely desireable,
maybe possible, probably requires bfd extension. At some point we
should kick it around some more.