From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by sourceware.org (Postfix) with ESMTP id 6ECCD384B0C1 for ; Mon, 22 Jun 2020 18:15:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6ECCD384B0C1 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-249-QpwUNPDuNvCkjhZo4xXikw-1; Mon, 22 Jun 2020 14:14:57 -0400 X-MC-Unique: QpwUNPDuNvCkjhZo4xXikw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AC6F3800C21; Mon, 22 Jun 2020 18:14:56 +0000 (UTC) Received: from host1.jankratochvil.net (ovpn-112-188.ams2.redhat.com [10.36.112.188]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DE57E19D61; Mon, 22 Jun 2020 18:14:55 +0000 (UTC) Date: Mon, 22 Jun 2020 20:14:53 +0200 From: Jan Kratochvil To: Mitch Souders Cc: gdb@sourceware.org Subject: Re: GDB reading eh_frame/eh_frame_hdr from disk Message-ID: <20200622181453.GA3471048@host1.jankratochvil.net> References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.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_H3, 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@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 18:15:09 -0000 On Fri, 19 Jun 2020 00:37:42 +0200, Mitch Souders wrote: > Is there any way to tell gdb to use the in-memory representation from the > inferior of the .eh_frame/.eh_frame_hdr sections when doing stack > unwinding? As best I can determine, gdb always reaches out to disk to find > .eh_frame/.eh_frame_hdr to do stack unwinding. Our product is doing some > runtime manipulation of these sections and gdb's current behavior is > undesired. I am not aware GDB (nor LLDB) could do that. elfutils stack (eu-stack) can do that. One can test it by deleting the file on disk (such as during update of a running daemon) and backtrace it. Jan $ cp -p /bin/sleep /tmp/xsleep;/tmp/xsleep 1m&p=$!;rm -f /tmp/xsleep;eu-stack -p $p;kill $p PID 3471191 - process TID 3471191: #0 0x00007f127d3c581e clock_nanosleep@@GLIBC_2.17 #1 0x00007f127d3cb1c7 __nanosleep #2 0x0000558ca6adba67 rpl_nanosleep #3 0x0000558ca6adb829 xnanosleep #4 0x0000558ca6ad87f0 main #5 0x00007f127d324042 __libc_start_main #6 0x0000558ca6ad88ce _start $ cp -p /bin/sleep /tmp/xsleep;/tmp/xsleep 1m&p=$!;rm -f /tmp/xsleep;gdb -p $p -batch -ex bt;kill $p warning: Could not load vsyscall page because no executable was specified 0x00007f36db01881e in ?? () #0 0x00007f36db01881e in ?? () #1 0x0000000000000000 in ?? () [Inferior 1 (process 3471210) detached]