From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26288 invoked by alias); 25 Jun 2007 16:08:46 -0000 Received: (qmail 26238 invoked by uid 48); 25 Jun 2007 16:08:36 -0000 Date: Mon, 25 Jun 2007 16:08:00 -0000 Message-ID: <20070625160836.26237.qmail@sourceware.org> From: "pmuldoon at redhat dot com" To: frysk-bugzilla@sourceware.org In-Reply-To: <20070625134256.4698.pmuldoon@redhat.com> References: <20070625134256.4698.pmuldoon@redhat.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug general/4698] Opening up a core file in the source window causes a backtrace X-Bugzilla-Reason: AssignedTo Mailing-List: contact frysk-bugzilla-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: frysk-bugzilla-owner@sourceware.org X-SW-Source: 2007-q2/txt/msg00419.txt.bz2 List-Id: ------- Additional Comments From pmuldoon at redhat dot com 2007-06-25 16:08 ------- (In reply to comment #3) > Are core files meant to be self containted ?\ Depends what you mean. Corefiles are not complete snapshots of an executable when it was running. Some segments are elided (not written) as they can be recreated later from looking at the linkmap table, and whether that segment has been written to, and reconstructing the metadata/maps from parsing each and every included solib in the linkmap table, looking for PT_LOAD headers. It does this now. > If so then this is a bad core file. Why is the executable needed ? To look at non elided segments (ie actually in the corefile), process data, thread data , auxv data) no executbale is needed. To read and reconstruct from elided segments, do backtraces the executable's .dynamic, .interp segments are needed. > If not then there is no safe way to figure out what the executable that was used That's the user specifiying the executable path is the safest > to create the is, in which case the user should specify it. Agree, but there is a requirement that corefiles locat it themselves. > So two sides to this: > fcore should make sure the information is correctly retrieved, failing that fcore can only put into the corefile the information it is provided via Proc. That is the infromation provided. This is the same information the kernel provides for its corefiles, so the reference implementation is correct. > frysk should be able to handle a case where the executable is unknown It does, normally. This is part bug on my side, too. The corefile found it's excutabke in the beginning /usr/bin/sleep, but when asked what it's executable is, it reported ./sleep which is what is stored in the core file. -- http://sourceware.org/bugzilla/show_bug.cgi?id=4698 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.