From owner-freebsd-hackers Fri Nov 28 17:37:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA23676 for hackers-outgoing; Fri, 28 Nov 1997 17:37:34 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA23666 for ; Fri, 28 Nov 1997 17:37:11 -0800 (PST) (envelope-from dawes@rf900.physics.usyd.edu.au) Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.8.5/8.8.2) id MAA26990; Sat, 29 Nov 1997 12:36:19 +1100 (EST) Message-ID: <19971129123619.61979@rf900.physics.usyd.edu.au> Date: Sat, 29 Nov 1997 12:36:19 +1100 From: David Dawes To: hackers@FreeBSD.ORG Subject: Re: Shared Libraries and debugging References: <199711272255.OAA18209@austin.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: ; from Charles Mott on Thu, Nov 27, 1997 at 04:40:35PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, Nov 27, 1997 at 04:40:35PM -0700, Charles Mott wrote: >On Thu, 27 Nov 1997, John Polstra wrote: >> Judging by the cause of the problem, I doubt that it ever worked. In >> order to examine shared libraries, gdb needs to look at the dynamic >> linker's table which records where they were loaded into memory. The >> dynamic linker has always recorded this information in a MAP_ANON >> region way up high in the address space. But such regions are not >> written to the core file when a core dump occurs. So gdb has not been >> able to get the information it needs. > >So memory allocated with mmap() is not dumped in a core file? Is this not >possible or just not desirable? Linux seems to (but then it uses ELF). I've seen an unfortunate side-effect of this on Linux when reading the mmapped MMIO area from a Millennium while dumping an Xserver core file. The result was a machine lockup because reads from a part of the MMIO area can initiate a graphics command. We worked around this by unmapping when receiving a trapped signal, but that doesn't help when signal trapping is turned off. David