This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: core files and shared libraries
- To: John Van Horne <jvhorne at guava-lx dot eng dot cosinecom dot com>
- Subject: Re: core files and shared libraries
- From: Daniel Jacobowitz <drow at mvista dot com>
- Date: Fri, 3 Aug 2001 15:38:55 -0700
- Cc: gdb at sources dot redhat dot com, jvhorne at cosinecom dot com
- References: <200108032223.PAA22169@guava-lx.eng.cosinecom.com>
On Fri, Aug 03, 2001 at 03:23:15PM -0700, John Van Horne wrote:
> I'm hoping that someone can help me with this problem.
>
> I'm running version 2.4.2 of the Linux kernel on an embedded PPC. I've
> applied a patch enables core file generation for multithreaded
> applications. This seems to work. However because of the number
> of threads, the amount of memory allocated by the application, and
> the limited filesystem space, I want to limit what goes into the core files.
> Setting the environment's core file size limit (e.g in bash with "ulimit -c")
> doesn't necessarily do what I want because it may generate a core
> file which does not include the stack.
>
> I've hacked at the kernel code which generates the ELF core file so that the
> only memory section it writes is the one which contains the stack. The
> note and reg sections are still generated. The problem I have now is
> that when I examine the stack using gdb, I get something with no symbols:
At a guess, you need to dump enough of the heap to get _DYNAMIC, the
linker's load map. Otherwise gdb will not know where shared libraries
were loaded.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer