From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11994 invoked by alias); 20 Dec 2018 00:16:34 -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 11902 invoked by uid 89); 20 Dec 2018 00:16:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=BAYES_00,KAM_STOCKGEN,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 spammy=83, 81, $84, PCs 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; Thu, 20 Dec 2018 00:16:25 +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 wBK0GI0U002791 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 19 Dec 2018 19:16:23 -0500 Received: by simark.ca (Postfix, from userid 112) id 829161E7B1; Wed, 19 Dec 2018 19:16:18 -0500 (EST) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 84DFA1E093; Wed, 19 Dec 2018 19:16:15 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 20 Dec 2018 00:16:00 -0000 From: Simon Marchi To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: GDB internal error in pc_in_thread_step_range In-Reply-To: <83ftutcy7p.fsf@gnu.org> References: <83h8kjr8r6.fsf@gnu.org> <100001f1b27aa7d90902a75d5db37710@polymtl.ca> <83a7m6tk92.fsf@gnu.org> <8336qxfpjo.fsf@gnu.org> <83tvjde68l.fsf@gnu.org> <83ftutcy7p.fsf@gnu.org> Message-ID: <659d33b5e4af35aea6c3aaef08559f31@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.6 X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00228.txt.bz2 On 2018-12-19 10:50, Eli Zaretskii wrote: > The symbol is the one shown by GDB: > > 0x0040126d in __register_frame_info () > Single stepping until exit from function __register_frame_info, > which has no line number information. > > Here it is as shown in the debugging session: > > 227 msymbol = lookup_minimal_symbol_by_pc_section (mapped_pc, > section); > (top-gdb) > 228 ALL_OBJFILES (objfile) > (top-gdb) p msymbol > $3 = {minsym = 0x10450d38, objfile = 0x10443b48} > (top-gdb) p msymbol.minsym.mginfo.name > $4 = 0x104485cd "__register_frame_info" > (top-gdb) p msymbol.minsym.mginfo > $5 = {name = 0x104485cd "__register_frame_info", value = {ivalue = 0, > block = 0x0, bytes = 0x0, address = 0x0, common_block = 0x0, > chain = 0x0}, language_specific = {obstack = 0x0, demangled_name > = 0x0}, > language = language_auto, ada_mangled = 0, section = 0} Ok. Well this is already strange. Why is there an mst_text (code) symbol with a value of 0? If your binary is anything like those I can produce with x86_64-w64-mingw32-gcc (and it looks similar, given the addresses you show), your "image base" is likely 0x400000, and "base of code" 0x1000 (0x401000 in absolute). I found this information using "objdump -x", in the header somewhere. I therefore expect all text symbols to be >= 0x401000. I would start digging why this text symbol with a value of 0 exists. It would be interesting to look at some other symbols in the msymbols vector. Are the other mst_text symbols >= 0x401000? When printing the symbols with "objdump -t", the addresses are also relative to 0x401000, but when they become minimal symbols in GDB, they are saved as the absolute address (e.g. a text symbol at 0x1c88 becomes 0x401000). Assuming this minimal symbol is wrong and assuming it wasn't there, then I guess the search would fail and we would fall in the "Cannot find bounds of current function" case of prepare_one_step? That would be appropriate in this case. >> In particular, I am looking for why we identified the symbol >> represented by MSYMBOL >> as the function containing PC. What is this symbol's name? That >> would be printed >> with MSYMBOL_LINKAGE_NAME(msymbol.minsym), I think. Or if you expand, >> "msymbol.minsym.mginfo.name". >> >> What is its address (should be msymbol.minsym.mginfo.value.address)? >> >> > >> >> How come by looking up a symbol for PC (what is PC's value, btw) we found this symbol? > > That's because it's the symbol with the lowest address that satisfies > all the conditions in lookup_minimal_symbol_by_pc_section. It goes > like this: > > The loop which does a binary search through the minsyms finds the the > symbol immediately preceding the address of PC is this: > > (top-gdb) p newobj > $28 = 26 > (top-gdb) p msymbol[newobj] > $29 = {mginfo = {name = 0x10448845 "_image_base__", value = { > ivalue = 4194304, block = 0x400000, bytes = 0x400000 "MZ\220", > address = 0x400000, common_block = 0x400000, chain = 0x400000}, > language_specific = {obstack = 0x0, demangled_name = 0x0}, > language = language_auto, ada_mangled = 0, section = 0}, size = > 0, > filename = 0x0, type = mst_abs, created_by_gdb = 0, target_flag_1 = > 0, > target_flag_2 = 0, has_size = 0, hash_next = 0x0, > demangled_hash_next = 0x0} > > (our PC is 0x40126d). > > Then this loop: > > /* Skip various undesirable symbols. */ > while (hi >= 0) > { > > decrements 'hi' all the way down to 5, because all the preceding > symbols have the type mst_abs: > > (top-gdb) p hi > $46 = 5 > (top-gdb) p msymbol[hi] > $47 = {mginfo = {name = 0x1044858d "__register_frame_info", value = { > ivalue = 0, block = 0x0, bytes = 0x0, address = 0x0, > common_block = 0x0, chain = 0x0}, language_specific = {obstack = 0x0, > demangled_name = 0x0}, language = language_auto, ada_mangled = 0, > section = 0}, size = 0, filename = 0x0, type = mst_text, > created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size > = 0, > hash_next = 0x0, demangled_hash_next = 0x0} > > Note that this symbol's address is zero. This symbol is then > returned, and so cache_pc_function_low becomes zero. Then we get to > this: > > cache_pc_function_high = minimal_symbol_upper_bound (msymbol); > > minimal_symbol_upper_bound then looks at the following symbols trying > to find the one whose address is different from zero: > > for (i = 1; MSYMBOL_LINKAGE_NAME (msymbol + i) != NULL; i++) > { > if ((MSYMBOL_VALUE_RAW_ADDRESS (msymbol + i) > != MSYMBOL_VALUE_RAW_ADDRESS (msymbol)) > && MSYMBOL_SECTION (msymbol + i) == section) > break; > } > > It finds such a symbol in the 10th entry: > > (top-gdb) p msymbol[1] > $76 = {mginfo = {name = 0x10448a55 "__set_app_type", value = {ivalue > = 0, > block = 0x0, bytes = 0x0, address = 0x0, common_block = 0x0, > chain = 0x0}, language_specific = {obstack = 0x0, > demangled_name = 0x0}, language = language_auto, ada_mangled = 0, > section = 0}, size = 0, filename = 0x0, type = mst_abs, > created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size > = 0, > hash_next = 0x0, demangled_hash_next = 0x0} > (top-gdb) p msymbol[2] > $77 = {mginfo = {name = 0x104487ad "_dll__", value = {ivalue = 0, > block = 0x0, bytes = 0x0, address = 0x0, common_block = 0x0, > chain = 0x0}, language_specific = {obstack = 0x0, > demangled_name = 0x0}, language = language_auto, ada_mangled = 0, > section = 0}, size = 0, filename = 0x0, type = mst_abs, > created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size > = 0, > hash_next = 0x0, demangled_hash_next = 0x0} > (top-gdb) p msymbol[3] > $78 = {mginfo = {name = 0x104483cd "_dll_characteristics__", value = > { > ivalue = 0, block = 0x0, bytes = 0x0, address = 0x0, > common_block = 0x0, chain = 0x0}, language_specific = {obstack = 0x0, > demangled_name = 0x0}, language = language_auto, ada_mangled = 0, > section = 0}, size = 0, filename = 0x0, type = mst_abs, > created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size > = 0, > hash_next = 0x0, demangled_hash_next = 0x0} > (top-gdb) p msymbol[3] > $79 = {mginfo = {name = 0x104483cd "_dll_characteristics__", value = > { > ivalue = 0, block = 0x0, bytes = 0x0, address = 0x0, > common_block = 0x0, chain = 0x0}, language_specific = {obstack = 0x0, > demangled_name = 0x0}, language = language_auto, ada_mangled = 0, > section = 0}, size = 0, filename = 0x0, type = mst_abs, > created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size > = 0, > hash_next = 0x0, demangled_hash_next = 0x0} > (top-gdb) p msymbol[4] > $80 = {mginfo = {name = 0x1044868d "_fpreset", value = {ivalue = 0, > block = 0x0, bytes = 0x0, address = 0x0, common_block = 0x0, > chain = 0x0}, language_specific = {obstack = 0x0, > demangled_name = 0x0}, language = language_auto, ada_mangled = 0, > section = 0}, size = 0, filename = 0x0, type = mst_abs, > created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size > = 0, > hash_next = 0x0, demangled_hash_next = 0x0} > (top-gdb) p msymbol[5] > $81 = {mginfo = {name = 0x1044fead "_loader_flags__", value = {ivalue > = 0, > block = 0x0, bytes = 0x0, address = 0x0, common_block = 0x0, > chain = 0x0}, language_specific = {obstack = 0x0, > demangled_name = 0x0}, language = language_auto, ada_mangled = 0, > section = 0}, size = 0, filename = 0x0, type = mst_abs, > created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size > = 0, > hash_next = 0x0, demangled_hash_next = 0x0} > (top-gdb) p msymbol[6] > $82 = {mginfo = {name = 0x1044ff9d "_minor_image_version__", value = > { > ivalue = 0, block = 0x0, bytes = 0x0, address = 0x0, > common_block = 0x0, chain = 0x0}, language_specific = {obstack = 0x0, > demangled_name = 0x0}, language = language_auto, ada_mangled = 0, > section = 0}, size = 0, filename = 0x0, type = mst_abs, > created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size > = 0, > hash_next = 0x0, demangled_hash_next = 0x0} > (top-gdb) p msymbol[7] > $83 = {mginfo = {name = 0x104487cd "_minor_os_version__", value = { > ivalue = 0, block = 0x0, bytes = 0x0, address = 0x0, > common_block = 0x0, chain = 0x0}, language_specific = {obstack = 0x0, > demangled_name = 0x0}, language = language_auto, ada_mangled = 0, > section = 0}, size = 0, filename = 0x0, type = mst_abs, > created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size > = 0, > hash_next = 0x0, demangled_hash_next = 0x0} > (top-gdb) p msymbol[8] > $84 = {mginfo = {name = 0x1044ff65 "_minor_subsystem_version__", > value = { > ivalue = 0, block = 0x0, bytes = 0x0, address = 0x0, > common_block = 0x0, chain = 0x0}, language_specific = {obstack = 0x0, > demangled_name = 0x0}, language = language_auto, ada_mangled = 0, > section = 0}, size = 0, filename = 0x0, type = mst_abs, > created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size > = 0, > hash_next = 0x0, demangled_hash_next = 0x0} > (top-gdb) p msymbol[9] > $85 = {mginfo = {name = 0x10448b35 "_rt_psrelocs_size", value = > {ivalue = 0, > block = 0x0, bytes = 0x0, address = 0x0, common_block = 0x0, > chain = 0x0}, language_specific = {obstack = 0x0, > demangled_name = 0x0}, language = language_auto, ada_mangled = 0, > section = 0}, size = 0, filename = 0x0, type = mst_abs, > created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size > = 0, > hash_next = 0x0, demangled_hash_next = 0x0} > (top-gdb) p msymbol[10] > $86 = {mginfo = {name = 0x1044fe8d "_major_image_version__", value = > { > ivalue = 1, block = 0x1, > bytes = 0x1 , > address = 0x1, common_block = 0x1, chain = 0x1}, language_specific = { > obstack = 0x0, demangled_name = 0x0}, language = language_auto, > ada_mangled = 0, section = 0}, size = 0, filename = 0x0, type = > mst_abs, > created_by_gdb = 0, target_flag_1 = 0, target_flag_2 = 0, has_size > = 0, > hash_next = 0x0, demangled_hash_next = 0x0} > > And so cache_pc_function_high becomes 1. Ok, from what I understand, all these "mst_abs" symbols do not represent addresses. They just represent numerical "values", like version numbers, alignment sizes, etc. So it seems right to skip them when looking for the minimal symbol preceding pc. It looks like minimal_symbol_upper_bound is buggy, in that it should not consider these mst_abs. If we are looking for the end of a memory range, we should not consider those symbols that do not even represent memory addresses... >> Actually, I think I would investigate this line in >> find_pc_partial_function: >> >> msymbol = lookup_minimal_symbol_by_pc_section (mapped_pc, section); >> >> This is where we ask the question "which is the closest minimal symbol >> that is <= than PC". >> I would then try to see if the returned msymbol makes sense. If you >> can give its name and >> address, it would be a good start. If we find it doesn't make sense, >> I'd start looking at >> why lookup_minimal_symbol_by_pc_section returned that. > > That's what I did. The problem seems to be that the low value of PC > doesn't allow GDB to find a reasonable symbol; what it finds are > symbols with very low addresses, which don't look like symbols > relevant to the issue at hand. I see the same symbols and addresses > in the output of "objdump -t" (I can show it if you want). If you could pastebin it, or send it as an attachment, I think it would be useful. Consider sending the output of "objdump -x", which I think gives a superset of "objdump -t". > Where do we go from here? I would say 1. investigate if the text symbol at address 0 really has business being there. 2. investigate if there should be some text symbol that should really contain 0x0040126d, that for some reason does not end up in GDB's minimal symbol table. Simon