From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 33BEC38708F3 for ; Wed, 4 Nov 2020 09:39:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 33BEC38708F3 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-458-a7eVFrt1NaONg3EJWtKgig-1; Wed, 04 Nov 2020 04:39:30 -0500 X-MC-Unique: a7eVFrt1NaONg3EJWtKgig-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DA9478030A7; Wed, 4 Nov 2020 09:39:29 +0000 (UTC) Received: from [10.36.115.38] (ovpn-115-38.ams2.redhat.com [10.36.115.38]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2A52A5D9EF; Wed, 4 Nov 2020 09:39:28 +0000 (UTC) To: William Adair Cc: gdb@sourceware.org References: From: Andrew Dinn Subject: Re: GDB Incorrectly Reads & Resolves Shared Library Symbols [MinGW-w64] Message-ID: Date: Wed, 4 Nov 2020 09:39:28 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, 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: Wed, 04 Nov 2020 09:39:34 -0000 Hi William, On 03/11/2020 23:20, William Adair wrote: > 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...) Well, as I said "After that all you need to do is familiarize with the gdb source!" ;-) I have not looked into shared lib code much but I believe minimal symbols are used to record details of symbols in those libs for which gdb does not have (maybe cannot have?) full info. The type definition is in symtab.h along with related types symbol and general_symbol_info. Note that symbol and minimal_symbol both (publicly) inherit common data from general_symbol_info which crops up all over the code base. n.b. your quickest way to see what is these types are is to use gdb: (outer) ptype minimal_symbol . . . (outer) ptype symbol . . . (outer) ptype general_symbol_info . . . The stuff about address ordering may be the issue but it sounds to me like this is a comment about how gdb expects its data to be organized. If something is missing/out of order in gdb's data that may be to do with the order in the shared lib or it may be because gdb has failed to read or sort something from the lib. gdb has a host of _debug vars you can set to trace what it is doing as it executes a program. This command will help you find them (outer) info var _debug The debug vars you probably want to set for tracing symtab processing can be enabled like this (outer) break main ... (outer) commands > set symbol_lookup_debug = 1 > set symtab_create_debug > end The above breakpoint with associated commands will set these debug vars when gdb starts running. I suggest you also look at the contents of the shared library outside of gdb using objdump and/or nm. That will tell you what gdb is trying to process and you may be able to compare it with the debug output to see whether any symbols is getting lost or discarded. > Thanks everyone for your time. You are welcome. Good luck. regards, Andrew Dinn -----------