From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44973 invoked by alias); 28 Sep 2016 16:37:32 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 44955 invoked by uid 89); 28 Sep 2016 16:37:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=sk:duaned, duane@duaneellis.com, duaneduaneelliscom, U*duane X-HELO: mx5.ptsecurity.com Received: from mx6.ptsecurity.com (HELO mx5.ptsecurity.com) (45.58.112.36) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 Sep 2016 16:37:21 +0000 Received: from dc1-mail-01.ptsecurity.ru (10.0.52.111) by ny-mx-02.ptsecurity.ru (10.6.20.7) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 28 Sep 2016 19:37:25 +0300 Received: from [10.0.72.136] (10.0.72.136) by dc1-mail-01.ptsecurity.ru (10.0.52.111) with Microsoft SMTP Server (TLS) id 15.1.466.34; Wed, 28 Sep 2016 19:37:17 +0300 Subject: Re: Custom core file To: , References: <20160928083121.5c1bb9f86d671edec44bb378f25c04cc.5416b9a60c.wbe@email03.godaddy.com> From: Nikolay Martyanov Message-ID: <55af2d92-9c32-2bd0-22e4-c869f3afe14d@ptsecurity.com> Date: Wed, 28 Sep 2016 16:37:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160928083121.5c1bb9f86d671edec44bb378f25c04cc.5416b9a60c.wbe@email03.godaddy.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: dc1-mail-01.ptsecurity.ru (10.0.52.111) To dc1-mail-01.ptsecurity.ru (10.0.52.111) X-SW-Source: 2016-09/txt/msg00073.txt.bz2 On 09/28/2016 06:31 PM, duane@duaneellis.com wrote: >>> So, I guess, dump/restore approach works only in two cases: >>> a) debugging live process you have attached to (it's not my case, as I >>> perform postmortem debug) >>> b) already has loaded core file, which provides a context via saved CPU >>> state - and it is the way I chose to follow. > For step (B) - first load a dummy (tiny) standard core file - that gives > you a debug context, think of it as a shim. Is it a common case for GDB? Can this "fake" context bring me some erroneous debug info? I had such an idea, but due to doubt I mentioned above, decided not even to try. Now I will =) Thanks, Nikolay