From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by sourceware.org (Postfix) with ESMTP id 080683851C2F for ; Thu, 21 May 2020 16:28:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 080683851C2F Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-363-xdAlwW_vO2ep8M6U-OW2Xw-1; Thu, 21 May 2020 12:28:29 -0400 X-MC-Unique: xdAlwW_vO2ep8M6U-OW2Xw-1 Received: by mail-wm1-f69.google.com with SMTP id l26so2042491wmh.3 for ; Thu, 21 May 2020 09:28: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:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kyt16cJP3PwGy2r75azHj6iuI8cQhWfiI6RtTyxiJbQ=; b=seslPZdnEG7gDOYmpeJBiMEcMTvXvfFcsgT0riGbbuOAPlTpoMlINEdqY9BwQY2tuk 1sNW5fTRA3LS223YHGY85YhNuBm9KCisdTqDRaFK5HEErs9SRJmC5UpA1krP+wPtCU6Z zz72ySitvWEeUGC0YChtdHYxJ8JxwERiMHCegQMtWzmcLDRNN9ErlNrh+aspgr3x7NSv u43NhhCfrzCtytW3WGPPU6owQxlcnLf7waiQUCx63mkxXzQYL10ZeYsrFTaLagK7A2Kl K5C/MxTOobpg9S57JAnnb6uKH+/naDBMIwWaAGmoEGRuwnXFMDtWhvlBem+h6Jral8hN VjDA== X-Gm-Message-State: AOAM530Elz0Qpsk2vPXct4/C75Vv70+y7Vxk5Fjq5vvAF21qMzCzuf+m AakWjL6VvrXToVbJSaLmylHwyDSayKD8RNfIafoQVRKI9ZLhZNJ1ZFz6hM5M1Lp7Hg0ZtO11PqF 2rS4BKtq9MGhAjNMINTLbFg== X-Received: by 2002:a05:600c:2055:: with SMTP id p21mr9961884wmg.127.1590078507640; Thu, 21 May 2020 09:28:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy0z9Vq2mCGgY3Lvip/sesOGy/7le1VnwfD53mFzmtE6mcpSR5u3uqPce852D/amxDSLiG0NQ== X-Received: by 2002:a05:600c:2055:: with SMTP id p21mr9961872wmg.127.1590078507417; Thu, 21 May 2020 09:28:27 -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 p17sm10976529wmi.3.2020.05.21.09.28.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 May 2020 09:28:26 -0700 (PDT) Subject: Re: [PATCH v2 4/5] Provide access to non SEC_HAS_CONTENTS core file sections To: Kevin Buettner References: <20200513171155.645761-1-kevinb@redhat.com> <20200513171155.645761-5-kevinb@redhat.com> <20200521005020.697d1bf1@f31-4.lan> <8d80af1d-ef03-2db7-6dd0-4e7fa8dba283@redhat.com> <20200521080937.42a276c0@f31-4.lan> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Thu, 21 May 2020 17:28:17 +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: <20200521080937.42a276c0@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=-8.1 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_H4, RCVD_IN_MSPIKE_WL, 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 16:28:36 -0000 On 5/21/20 4:09 PM, Kevin Buettner wrote: > On Thu, 21 May 2020 15:23:00 +0100 > Pedro Alves wrote: >> >> Thus, take 3: >> >> The question should have been -- why are there SEC_ALLOC && !SEC_HAS_CONTENTS >> load segments for that data that should be read from the executable? >> Or rather, why did the kernel decide to output a .bss-like load segment with >> no contents for that mapping? If there wasn't such a load segment >> in the core, then we wouldn't need this heuristic. This is looking like a kernel >> bug to me. Like, if the mapping was file backed and wasn't touched, then it >> should have been skipped. If it was touched (or for some other reason >> that could justify dumping the mapping), then the kernel should have >> included its current contents in the dump, instead of >> indicating "no contents". No? > > The kernel simply dumps all of the memory that it knows about. It > doesn't try to filter anything out. Should it determine that an area > has a file based backing or that it was never written to (or several other > conditions: MADV_DONTDUMP, I/O areas, etc), it'll skip dumping the > contents, but will still dump a header. I see. I thought I'd check what other OSs do, so I found a Solaris 11 box, and did a bit of testing with a simple #include int main { abort (); } program. Solaris has this coreadm utility that lets you configure what kind of data is dumped on the core: https://docs.oracle.com/cd/E19253-01/816-5166/coreadm-1m/index.html Comparing dumps with $ coreadm -I none vs $ coreadm -I default I see that Solaris dumps the exact same set of segments in both cases, though in the "none" case, segments whose contents were not dumped have headers with !CONTENTS. Like: - 6 load2 00000000 0000000000400000 0000000000000000 00000000 2**0 - ALLOC, READONLY, CODE + 6 load2 00001000 0000000000400000 0000000000000000 00003068 2**0 + CONTENTS, ALLOC, LOAD, READONLY, CODE So seems like this isn't a Linux-specific thing... I think this means that we're probably going to be stuck with this basically forever, and should do the best we can with the info we have. Let me answer the other question about the info proc mappings idea in response to your previous email. Thanks, Pedro Alves