From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id 691793851C25 for ; Wed, 20 May 2020 16:45:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 691793851C25 Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-198-eajFhPBaPz27yldFWzyNrQ-1; Wed, 20 May 2020 12:45:31 -0400 X-MC-Unique: eajFhPBaPz27yldFWzyNrQ-1 Received: by mail-wm1-f70.google.com with SMTP id n66so1489566wme.4 for ; Wed, 20 May 2020 09:45:31 -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=cemFfiIM+L0RbbbkyAgq7jJeFnXI/NZkvB8aeTETlAo=; b=QWm9ZJlaurXCl7bCk1jpoNCimVfoSxJJFwqWhbC+1cS/ODZTbToZczNhRGE5ut2H6i 7jz2QTvK+ZXJBpn4CHpzvXxt+1MvyoGOAYyYOqbd6QR1xLmiT4FUzmLxH7OS6Dq5mcds CgJScH1MfRl4RaIXS2R/fxn/LXxH+cFDkoXTWj/CPShFLzHX/8tWCC6/HElXwaaSofXj Q+Nnnm/72GNfHSCe5AnGIrEaQl8ctnrTnLSLoL5+8vlQhqgiGw0sMnpw6oPivyKiE7lW QaSM5EiybzTiU4OmSTU8YmRpzKMS1/HZy9XpE9tUJy0iDw0NM3KMN0znh1YIaCgQ3slP HK5w== X-Gm-Message-State: AOAM533yCooEO/H7p/vqt5PxFjRFvvYeSFaqkD4sbQqcXDy0tosentm5 dhZ3spUAhrNaRxQABW4Jld4oQ39vXAU10W6jl0sPz8HLZ3dIiwxXs6hppf91GVTHcukgtsxKct3 yOx0eRvePcn44rRb32VFpTw== X-Received: by 2002:adf:decb:: with SMTP id i11mr5286074wrn.172.1589993130067; Wed, 20 May 2020 09:45:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzrsv3n+pfAoK+LiEbNzr1EoBsLaaZLmW2bIXkteThx7YaMPsXDxwDn/XJREeNMm4R9TU+vMw== X-Received: by 2002:adf:decb:: with SMTP id i11mr5286057wrn.172.1589993129769; Wed, 20 May 2020 09:45:29 -0700 (PDT) Received: from ?IPv6:2001:8a0:f909:7b00:56ee:75ff:fe8d:232b? ([2001:8a0:f909:7b00:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id v5sm3384603wrr.93.2020.05.20.09.45.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 May 2020 09:45:29 -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> From: Pedro Alves Message-ID: Date: Wed, 20 May 2020 17:45:28 +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: <20200513171155.645761-5-kevinb@redhat.com> 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.9 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: Wed, 20 May 2020 16:45:42 -0000 On 5/13/20 6:11 PM, Kevin Buettner via Gdb-patches wrote: > Consider the following program: > > - - - mkmmapcore.c - - - > > static char *buf; > > int > main (int argc, char **argv) > { > buf = mmap (NULL, 8192, PROT_READ | PROT_WRITE, > MAP_ANONYMOUS | MAP_PRIVATE, -1, 0); > abort (); > } > - - - end mkmmapcore.c - - - > > Compile it like this: > > gcc -g -o mkmmapcore mkmmapcore.c > > Now let's run it from GDB. I've already placed a breakpoint on the > line with the abort() call and have run to that breakpoint. > > Breakpoint 1, main (argc=1, argv=0x7fffffffd678) at mkmmapcore.c:11 > 11 abort (); > (gdb) x/x buf > 0x7ffff7fcb000: 0x00000000 > > Note that we can examine the memory allocated via the call to mmap(). > > Now let's try debugging a core file created by running this program. > Depending on your system, in order to make a core file, you may have to > run the following as root (or using sudo): > > echo core > /proc/sys/kernel/core_pattern > > It may also be necessary to do: > > ulimit -c unlimited > > I'm using Fedora 31. YMMV if you're using one of the BSDs or some other > (non-Linux) system. > > This is what things look like when we debug the core file: > > [kev@f31-1 tmp]$ gdb -q ./mkmmapcore core.304767 > Reading symbols from ./mkmmapcore... > [New LWP 304767] > Core was generated by `/tmp/mkmmapcore'. > Program terminated with signal SIGABRT, Aborted. > #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 > 50 return ret; > (gdb) x/x buf > 0x7ffff7fcb000: Cannot access memory at address 0x7ffff7fcb000 > > Note that we can no longer access the memory region allocated by mmap(). > > Back in 2007, a hack for GDB was added to _bfd_elf_make_section_from_phdr() > in bfd/elf.c: > > /* Hack for gdb. Segments that have not been modified do > not have their contents written to a core file, on the > assumption that a debugger can find the contents in the > executable. We flag this case by setting the fake > section size to zero. Note that "real" bss sections will > always have their contents dumped to the core file. */ > if (bfd_get_format (abfd) == bfd_core) > newsect->size = 0; > > You can find the entire patch plus links to other discussion starting > here: > > https://sourceware.org/ml/binutils/2007-08/msg00047.html > > This hack sets the size of certain BFD sections to 0, which > effectively causes GDB to ignore them. I think it's likely that the > bug described above existed even before this hack was added, but I > have no easy way to test this now. > > The output from objdump -h shows the result of this hack: > > 25 load13 00000000 00007ffff7fcb000 0000000000000000 00013000 2**12 > ALLOC > > (The first field, after load13, shows the size of 0.) > > Once the hack is removed, the output from objdump -h shows the correct > size: > > 25 load13 00002000 00007ffff7fcb000 0000000000000000 00013000 2**12 > ALLOC > > (This is a digression, but I think it's good that objdump will now show > the correct size.) > > If we remove the hack from bfd/elf.c, but do nothing to GDB, we'll > see the following regression: > > FAIL: gdb.base/corefile.exp: print coremaker_ro > > The reason for this is that all sections which have the BFD flag > SEC_ALLOC set, but for which SEC_HAS_CONTENTS is not set no longer > have zero size. Some of these sections have data that can (and should) > be read from the executable. (Sections for which SEC_HAS_CONTENTS > is set should be read from the core file; sections which do not have > this flag set need to either be read from the executable or, failing > that, from the core file using whatever BFD decides is the best value > to present to the user - it uses zeros.) > > At present, due to the way that the target strata are traversed when > attempting to access memory, the non-SEC_HAS_CONTENTS sections will be > read as zeroes from the process_stratum (which in this case is the > core file stratum) without first checking the file stratum, which is > where the data might actually be found. > > What we should be doing is this: > > - Attempt to access core file data for SEC_HAS_CONTENTS sections. > - Attempt to access executable file data if the above fails. > - Attempt to access core file data for non SEC_HAS_CONTENTS sections, if > both of the above fail. > > This corresponds to the analysis of Daniel Jacobowitz back in 2007 > when the hack was added to BFD: > > https://sourceware.org/legacy-ml/binutils/2007-08/msg00045.html > > The difference, observed by Pedro in his review of my v1 patches, is > that I'm using "the section flags as proxy for the p_filesz/p_memsz > checks." So, as discussed at , I still think that this is an heuristic, and that we're trading one bug for another. It does seem like the bug that we're fixing is more important than the one we're introducing, so if there's really nothing else in the core file that would distinguish the coremaker_ro case from an anonymous mapping that should be read from the core (i.e., read as zeroes), then I suppose this is the best we can do, and the patch looks good to me. I would like to see the commit log and the comments slightly adjusted to mention this, though. Could you remind me again why is it that the core dump includes a load segment for coremaker_ro in the first place? If this is read-only data, why did the kernel decide to output a bss-like load segment for it? Thanks, Pedro Alves