From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22246 invoked by alias); 23 Dec 2018 15:33:12 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 22235 invoked by uid 89); 23 Dec 2018 15:33:11 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=am, surprised, describing X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 23 Dec 2018 15:33:10 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id wBNFWvmE007856 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 23 Dec 2018 10:33:02 -0500 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 2197C1E4C2; Sun, 23 Dec 2018 10:32:57 -0500 (EST) Subject: Re: GDB internal error in pc_in_thread_step_range To: Eli Zaretskii , Joel Brobecker Cc: gdb-patches@sourceware.org References: <8336qxfpjo.fsf@gnu.org> <83tvjde68l.fsf@gnu.org> <83ftutcy7p.fsf@gnu.org> <659d33b5e4af35aea6c3aaef08559f31@polymtl.ca> <837eg4cick.fsf@gnu.org> <988ca92d2c5c976fbea57c2381eb6279@polymtl.ca> <834lb6ar3g.fsf@gnu.org> <20181223053501.GC5246@adacore.com> <834lb49sib.fsf@gnu.org> From: Simon Marchi Message-ID: Date: Sun, 23 Dec 2018 15:33:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <834lb49sib.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00286.txt.bz2 On 2018-12-23 10:23 a.m., Eli Zaretskii wrote: >> Date: Sun, 23 Dec 2018 09:35:02 +0400 >> From: Joel Brobecker >> Cc: Eli Zaretskii , gdb-patches@sourceware.org >> >>>>> Side-question, are there some debug symbols in the binary that could >>>>> describe this location? >>>> >>>> How do I know that? >>> >>> I would normally use "readelf --debug-dump" to look at the DWARF info, but >>> since this is not an ELF, I don't know. >> >> Objdump has the same kind of functionality for both DWARF and >> the symbol table (--dwarf, -t, -T, etc). > > Yes. But in what part of its output would you expect to see debug > symbols that describe this location? > If you use "objdump --dwarf=info ", then you can see some nodes representing subprograms (functions), like this: <1><51>: Abbrev Number: 5 (DW_TAG_subprogram) <52> DW_AT_external : 1 <52> DW_AT_name : (indirect string, offset: 0x257b): main <56> DW_AT_decl_file : 1 <57> DW_AT_decl_line : 6 <58> DW_AT_decl_column : 5 <59> DW_AT_type : <0x4a> <5d> DW_AT_low_pc : 0x1119 <65> DW_AT_high_pc : 0xb <6d> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <6f> DW_AT_GNU_all_call_sites: 1 Here, DW_AT_high_pc is actually an offset relative to DW_AT_low_pc. This means my function main's range is [0x1119,0x1119+0xb[. So you could search in that output for "__mingw_CRTStartup", to see if there's a node describing that function. Honestly, I would be quite surprised if you had DWARF info for it but not a basic COFF symbol, but it costs nothing to check. Simon