From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) by sourceware.org (Postfix) with ESMTPS id 144C6384B0C1 for ; Mon, 22 Jun 2020 18:17:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 144C6384B0C1 Received: by mail-il1-x12c.google.com with SMTP id e11so16829290ilr.4 for ; Mon, 22 Jun 2020 11:17:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nH55zg6hZm/LMVdSwo7Yy6Ch+rT5oCQ4QfrQCNXxQ/s=; b=aipufofBb4pmQLPd5JICdoD1RRTqvbMYbiUV4xUx2EvEcyRRw3gDrrcq+8agZq3dZi 7ak+4uxCm0D7RSUcHd7L+IDsZT67t5Ai1UQ1+9rt5mtJStuU3ocI8+w2KSjE1hLSvgB6 VoEKQRBtjFaGr1pK1wNk8jT5dXyT5Jfhpu9dnjN/MfBablLQWqvM4MvobvObO2R9GXih UpvzyypfCHkmSaKfhMKQYXyjWOdxTEwK+wY5iZzkypUcLPK3DxguQnzisM67nAJ067QJ j7cyY/tKiF47SRsCcvdnGAAnfAokNvJf+sz6/JukNiIob0PW41BD/wPASzD6a6ioAMTA 9TZA== X-Gm-Message-State: AOAM5334cdqI8pns+d+6ZoUQnN4u5bhBjVur7+/U9gbECru4a3NqKblj ARDBNlSg42hJy/6CWsPX1m76sIiYCb7mpvjH2FM98KS2sHw= X-Google-Smtp-Source: ABdhPJym4ta+0rxSbqtu8AGB0DdUeERG4JaL877wnoCXQMLlmBpi+ZF+iVNoicmUZAtXXMjgKtVU2pl1slYVaoY4OeU= X-Received: by 2002:a92:5f9c:: with SMTP id i28mr19162625ill.25.1592849819442; Mon, 22 Jun 2020 11:16:59 -0700 (PDT) MIME-Version: 1.0 References: <2733a6b4-29ef-9fb6-3165-215501912d95@simark.ca> In-Reply-To: <2733a6b4-29ef-9fb6-3165-215501912d95@simark.ca> From: Sterling Augustine Date: Mon, 22 Jun 2020 11:16:48 -0700 Message-ID: Subject: Re: GDB reading eh_frame/eh_frame_hdr from disk To: Simon Marchi Cc: Mitch Souders , gdb@sourceware.org X-Spam-Status: No, score=-21.1 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL 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: Mon, 22 Jun 2020 18:17:01 -0000 The command: set trust-readonly-sections [on|off] toggles reading from memory vs reading from disk. The default is off, so unless you have a weird target or a strange script, you should be getting it from memory already. But it isn't hard to change to see if that fixes your problem. On Mon, Jun 22, 2020 at 11:08 AM Simon Marchi wrote: > On 2020-06-18 6:37 p.m., 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. > > If the section is allocated in the process, then I'd expect GDB to read > it from memory (when there's a process). You would need to step into > GDB when it's doing one such read to see which target ends up handling > the memory read. > > Simon >