From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by sourceware.org (Postfix) with ESMTP id 51D2E38708FF for ; Thu, 21 May 2020 17:06:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 51D2E38708FF Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-90-1u47-MWePICuZEefejuMVw-1; Thu, 21 May 2020 13:06:28 -0400 X-MC-Unique: 1u47-MWePICuZEefejuMVw-1 Received: by mail-wr1-f70.google.com with SMTP id e14so3151357wrv.11 for ; Thu, 21 May 2020 10:06:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kOBoenrSv+tL1kjgSlBx/T+idrmAOyfO3n69wsSu+Gk=; b=EkxCLVrl+14t8ymSQBoOwNCUyr0wBepFqGUo/0Ja19pgq50YUtcwSfGP+gfZESaovV B9P/LCSoBU9sqx9X2oAT9dRszF16mNt1vC6Bs1gaKeWd4NzpyJFDDfoaaNgQYihuvXJy ZhKBTWxxUuOInxWJSbIAeFf4mxPsWQdXqlie+6scYoiAB6mQHM458rk/MD9YB+RwtBv1 MrwaSB3JKPr8CDxVClwmv/oDwgXHFhDwRtTanCVuaNOlwKmS1UU5sKUDKHcDTdswl+DZ 9/xiq6ZcqzAxr6oUS54lnYm3rW7geiU7ZRPYGZsl8N1fnHTDbM/Dhyjj9/K41l6gFa5i qX+Q== X-Gm-Message-State: AOAM5308fiKCEUqRBL4+9ecEpmS4LM/ehLPHk9MYd2L3h03AVH8GsB/h Qqlbc0+XrGLSp6vMpXbVbhj5EzHVjOFmdEcQmj7erwQZTFR9+JOigFKYKJ8ONyTNqQYu6msK7nv tTsEIcUTt1p54y04oFtkwZA== X-Received: by 2002:adf:f6c4:: with SMTP id y4mr10077790wrp.81.1590080786810; Thu, 21 May 2020 10:06:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJywkGWevuYSKHFiUNcMfzy5XQVEwQIzxV0+yML1cxyepX0zTu/nyp2kYYe+2i4dWCsXq520kQ== X-Received: by 2002:adf:f6c4:: with SMTP id y4mr10077780wrp.81.1590080786609; Thu, 21 May 2020 10:06:26 -0700 (PDT) Received: from ?IPv6:2001:8a0:f909:7b00:2327:23ca:3e56:ef5f? ([2001:8a0:f909:7b00:2327:23ca:3e56:ef5f]) by smtp.gmail.com with ESMTPSA id m23sm7198140wmg.45.2020.05.21.10.06.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 May 2020 10:06:26 -0700 (PDT) Subject: Re: [PATCH v2 4/5] Provide access to non SEC_HAS_CONTENTS core file sections To: Kevin Buettner , gdb-patches@sourceware.org References: <20200513171155.645761-1-kevinb@redhat.com> <20200513171155.645761-5-kevinb@redhat.com> <20200521005020.697d1bf1@f31-4.lan> From: Pedro Alves Message-ID: <29ef36ae-c582-44e7-aaf7-fdef10249455@redhat.com> Date: Thu, 21 May 2020 18:06:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20200521005020.697d1bf1@f31-4.lan> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2020 17:06:31 -0000 On 5/21/20 8:50 AM, Kevin Buettner via Gdb-patches wrote: > On Wed, 20 May 2020 17:45:28 +0100 > Pedro Alves wrote: > On Linux, we're able to do "info proc mappings" when looking at a > corefile. Linux core files include a .note.linuxcore.file/pid section > which contain the map data that you see when running "info proc > mappings". > > It may be possible to use these mappings to provide a more accurate > view of memory contents when working with a core file. In addition > to file backed data that we already know about from the executable and > shared libraries, there may be additional file backed data that can > be found via files listed in the .note section mentioned earlier. Or, > as I found while investigating that one of those weird F27 mappings, > there may be data from a shared library which can't be found in > what GDB knows about when loading the shared library. (In that > particular case, the memory region in question contained some > vtable data prior to being remapped - though I'm guessing about > the remapping bit.) Yeah, that's a good idea. > > If you think it worth pursuing, I can look at using the core-provided > proc mapping information to provide a more accurate view of memory > when looking at a core dump. I think it's worth pursuing. If we have proc mappings data, we could only read from the exec file first if the mapping is file-backed. That sounds like would plug the ambiguity. > > If I do this, is it still worth pushing this v2 series first? Or should > it wait until I attempt to incorporate info from the .note section? I'd say give it a try, see if it would be too complicated. If it isn't, then I think it would be nice to merge it all together. Thanks, Pedro Alves