From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95700 invoked by alias); 20 Mar 2015 22:09:05 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 95690 invoked by uid 89); 20 Mar 2015 22:09:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 20 Mar 2015 22:09:03 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id AEEE5B6E68 for ; Fri, 20 Mar 2015 22:09:02 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2KM91Ul016647; Fri, 20 Mar 2015 18:09:01 -0400 Message-ID: <550C9A7C.90705@redhat.com> Date: Fri, 20 Mar 2015 22:09:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Sergio Durigan Junior CC: GDB Patches Subject: Re: [PATCH 2/2] Documentation and testcase References: <1426807358-18295-1-git-send-email-sergiodj@redhat.com> <1426807358-18295-3-git-send-email-sergiodj@redhat.com> <550C7905.9090501@redhat.com> <87mw37wfd6.fsf@redhat.com> In-Reply-To: <87mw37wfd6.fsf@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-03/txt/msg00678.txt.bz2 On 03/20/2015 09:03 PM, Sergio Durigan Junior wrote: >> > If not (I assume not), we could test that by loading the core >> > into gdb, but _not_ the program, and then disassembling a function's >> > address. It should fail. Then load the program and disassemble >> > again. It should work now. Or something along those lines. > Hm, OK. I guess I will try this approach, and if it doesn't happen then > I will see about doing a regular file-backed mapping. Thanks. If that approach doesn't work (for some odd reason), let's try to come up with another approach that still makes sure that the program's .text is not dumped, instead of mapping some other file. It's important that we don't regress that specifically. > I'll submit another revision of the series when I have something. Thanks. Thanks, Pedro Alves