From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) by sourceware.org (Postfix) with ESMTPS id 2D3DF3939C10 for ; Thu, 18 Jun 2020 22:37:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2D3DF3939C10 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=runsafesecurity.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=mitch@runsafesecurity.com Received: by mail-il1-x135.google.com with SMTP id j19so7531484ilk.9 for ; Thu, 18 Jun 2020 15:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=runsafesecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=u4SLa7/JEndtnZlBBmonWfPTFcs8RG+1vm3E7AOnRgg=; b=cimz3tx3aqadUoSWVa1rthGKSfh6xddGJOR9PvCl34QSTW0wqolHaO8EZxdMj3cVf6 V/xBcYiW7FJByPSnvD9SbRBbx6ujsMGlGfxE5r3lLRpyb7wFokJMUBSPxbuSAiYNd1mu mUYNjh4YMKHbAvE/u2fX13MvRuizQRIx+UuvegUdq7Gn3lXdE3r0LVdv1OFADpLEbLvN ENmqH/v9hxk19Etm5K5CquVgndOZ4TaHTW+RuCrChGGjXtHNUdu3UeDgfRioMInW0PGD 0M44QDtEm9zOdLD8ExcgL7EAH0j0BA3214hosaaFpdQy6R+OdHMkl+7lXEaKCdO/2wOV D15w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=u4SLa7/JEndtnZlBBmonWfPTFcs8RG+1vm3E7AOnRgg=; b=dXlP+BUCmn7ICI9m7ocMFJoir/BaNTDtWM8MJrLgapLmiOI/f7K4SiVE6xQ/iH9Omm lxzyp4wkYFWLI4Q8Bg2xKPfI91YRTzDAlGb7BjAsWZ4qnvdoVIhsOl6x5sBolvXhw8k6 AhM6Ug20ybzpAqAMZ/yxtbE7WoeQcRSLlzMvxsMUXOluL9qLWx+YTt33H3M/ZyurD7gY 9ixH9EUjuzV5l3tBkeSMHevZHhTq0rcINzLmt+EQL1/YBbS7qmon2NC1P9+aS2pojusP 1odn8QjegXWUs+bppS2eSdJ2HjGyypUkQaQKwdFzN13KOLPFOW+6EIGh7xJwqhMev+Wp 49fw== X-Gm-Message-State: AOAM531FB2767Xnu6b+CQ2YXB25rH+khdoMbXjpb02F8d3xHpf2PW4bH PLNbAGUDgAgkTyLCiMLPoMA0pCmrxHT8SNkEUFLVUSy1 X-Google-Smtp-Source: ABdhPJyuv25C+A77NutwKzxWFbLBVm+4RtOZUyTZG5HrK1sdLf1h0bJ+mi5bU30BTbIXNbRy+a9XLHqvujAQdRURj/g= X-Received: by 2002:a92:d0a:: with SMTP id 10mr796297iln.162.1592519872482; Thu, 18 Jun 2020 15:37:52 -0700 (PDT) MIME-Version: 1.0 From: Mitch Souders Date: Thu, 18 Jun 2020 15:37:42 -0700 Message-ID: Subject: GDB reading eh_frame/eh_frame_hdr from disk To: gdb@sourceware.org X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Thu, 18 Jun 2020 22:37:54 -0000 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. -- -Mitch