From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93385 invoked by alias); 19 Dec 2018 15:50:41 -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 93330 invoked by uid 89); 19 Dec 2018 15:50:40 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=BAYES_00,KAM_STOCKGEN,SPF_PASS autolearn=no version=3.3.2 spammy=lowest, 81, 83, $84 X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Dec 2018 15:50:31 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gZe77-0003JQ-Pc for gdb-patches@sourceware.org; Wed, 19 Dec 2018 10:50:29 -0500 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40261) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gZe76-0003Hq-BE; Wed, 19 Dec 2018 10:50:25 -0500 Received: from [176.228.60.248] (port=2547 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gZe75-0000c2-FI; Wed, 19 Dec 2018 10:50:24 -0500 Date: Wed, 19 Dec 2018 15:50:00 -0000 Message-Id: <83ftutcy7p.fsf@gnu.org> From: Eli Zaretskii To: Simon Marchi CC: gdb-patches@sourceware.org In-reply-to: (message from Simon Marchi on Sun, 16 Dec 2018 13:06:27 -0500) Subject: Re: GDB internal error in pc_in_thread_step_range References: <83h8kjr8r6.fsf@gnu.org> <100001f1b27aa7d90902a75d5db37710@polymtl.ca> <83a7m6tk92.fsf@gnu.org> <8336qxfpjo.fsf@gnu.org> <83tvjde68l.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00223.txt.bz2 > Cc: gdb-patches@sourceware.org > From: Simon Marchi > Date: Sun, 16 Dec 2018 13:06:27 -0500 > > >>> cache_pc_function_low = BMSYMBOL_VALUE_ADDRESS (msymbol); > >>> cache_pc_function_name = MSYMBOL_LINKAGE_NAME (msymbol.minsym); > >>> cache_pc_function_section = section; > >>> cache_pc_function_high = minimal_symbol_upper_bound (msymbol); > >>> cache_pc_function_block = nullptr; > >>> > >>> This is part of find_pc_partial_function. I verified that > >>> minimal_symbol_upper_bound returns 1 in this case, and that this value > >>> of 1 is assigned here: > >>> > >>> obj_section = MSYMBOL_OBJ_SECTION (minsym.objfile, minsym.minsym); > >>> if (MSYMBOL_LINKAGE_NAME (msymbol + i) != NULL > >>> && (MSYMBOL_VALUE_ADDRESS (minsym.objfile, msymbol + i) > >>> < obj_section_endaddr (obj_section))) > >>> result = MSYMBOL_VALUE_ADDRESS (minsym.objfile, msymbol + i); <<<<<< > >>> else > >>> > >>> Once again, I'm not an expert on this stuff, but just thinking about > >>> the situation, what else could GDB return in this case? > >> > >> This means that BMSYMBOL_VALUE_ADDRESS (msymbol) returned 0? What is that symbol? 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} > 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. > 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). Where do we go from here? Thanks.