From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id y7pQMMLloV+IQQAAWB0awg (envelope-from ) for ; Tue, 03 Nov 2020 18:20:34 -0500 Received: by simark.ca (Postfix, from userid 112) id B23851F08B; Tue, 3 Nov 2020 18:20:34 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_REPLYTO_END_DIGIT,MAILING_LIST_MULTI, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id E89CC1E552 for ; Tue, 3 Nov 2020 18:20:33 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4EF0C3842435; Tue, 3 Nov 2020 23:20:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4EF0C3842435 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1604445633; bh=r0389IAygAwtQzj3nDByzHPCU79SHvkb3qAsGFNMsk8=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=xcW6R4Vfk5ysClF12Hi7gtj+SSK4Uw67O5qvFvXTQPEJ49QN26BZR2JMcBGlIWR55 l/pBhtGB9F+nhghDW3JZyTPnqNkBVeTFhP7lc7pYIw1pdGAGTZiEo/RmjFLXUuK79Y 1mwYMe5b+hMr+qUIMnAtUCd/xbiLAIgGIhvsG7Qg= Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) by sourceware.org (Postfix) with ESMTPS id AE41E386F45A for ; Tue, 3 Nov 2020 23:20:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AE41E386F45A Received: by mail-io1-xd2e.google.com with SMTP id s24so13487813ioj.13 for ; Tue, 03 Nov 2020 15:20:30 -0800 (PST) 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=2EMktkVKunVk5tnqfLi3TA55zCwDkjNxjUSWf7dKo0o=; b=fYrWqPKoI3M7UpxwBYCpZL0YcRSE1jpeO0RFGaXlIzAMK3q2MhhVQRuEAnrsvHFy8n KJvaniUJlDsP+MWYoErHsS0p8dD92n07l+64uLOlbLkCPKIJrfkaWTtMA0ENfs9YifmR SBExNalId6F74SfC2R+pUIjJnEQQGWOROGINV9i5NT+2MCyjRsR96ocZLP/5UnH2Zgfl eRMRz2Pgg5rCRnNDBaRlKEZR0bwvruJnFISTu5Yf8LXjqYqsxfzVf5+M39U8zO1rfUlW p2OODa6ZidzqFEkB4HmhQsTapbvqr6xzpgcQY801F9dSxMYiLxu9BqzxsdX5lHX8Ydqq cZxA== X-Gm-Message-State: AOAM531qjKy3G0I04+RFPqHesvHpG6SYrgaIEHd2Y0xGv80+LMa3z6dE LXzyI2AGX9yx2SiNKUwMvAOZYAJXr/JIkm/tOMo= X-Google-Smtp-Source: ABdhPJxgSpF3fkG4NK/Fm6xLgUzQOPlZ15PGrhBTt9SdNNDO0KNIcSPABnnLaqOC9PO/ftMDB6asXZRx9QozRHbt8Ec= X-Received: by 2002:a05:6638:120d:: with SMTP id n13mr12251664jas.35.1604445630284; Tue, 03 Nov 2020 15:20:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 3 Nov 2020 18:20:19 -0500 Message-ID: Subject: Re: GDB Incorrectly Reads & Resolves Shared Library Symbols [MinGW-w64] To: Andrew Dinn 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: , From: William Adair via Gdb Reply-To: William Adair Cc: gdb@sourceware.org Errors-To: gdb-bounces@sourceware.org Sender: "Gdb" Andrew, Great feedback. It was a bit tricky to figure out how GDB was executing at first in main(), but I realized that backtrace_command_1 was the function I'm looking for in the stack.c file. The stack trace eventually hits print_frame_info()->print_frame() [which relies on find_frame_sal()] -> find_frame_funname -> lookup_minimal_symbol_by_pc() -> lookup_minimal_symbol_by_pc_section() A few immediate questions come to mind: What is the minimal symbol table? How can I verify that PC is pointing to the section that the actual symbol being executed resides in? Lastly, there's a comment: This code assumes that the minimal symbols are sorted by ascending address values. Does this imply that if the actual symbol for the PC has a lower address than the PC that the symbol will be wrong? (I wonder if this is what is happening in my case...) Thanks everyone for your time. On Sun, Nov 1, 2020 at 1:28 PM Andrew Dinn wrote: > On 31/10/2020 23:26, William Adair via Gdb wrote: > > Can anyone recommend a way to start debugging GDB? I've found that when I > > compile a 32-bit shared library that GDB is unable to correctly resolve > the > > symbols in the image and set breakpoints. Even when I reach a segfault > and > > print the backtrace, the symbols are incorrect or flat out missing. I > > already verified that the image has .debug_* sections as would be > required > > for DWARF debugging, so I'm perplexed as to why GDB cannot correctly > > resolve it and am looking for guidance. > Well you can, of course, use your currently installed gdb to debug gdb. > > Build gdb from a downloaded src tree using > > make install PREFIX=/path/to/install/dir CFLAGS=-g CXXFLAGS=-g. > > Then run > > gdb --fullname /path/to/my/newly/built/gdb. > > When you type run you will enter a nested gdb that you can debug. > > Hint: before typing run type > > (gdb) set prompt (outer) > > That way you can distinguish prompts in the outer gdb from prompts in > the inner gdb. > > n.b.b. make sure to type a space after (outer) or your typing will start > right next to the closing bracket > regards, > > After that all you need to do is familiarize wiht the gdb source! > > > Andrew Dinn > ----------- > >