From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103597 invoked by alias); 7 Dec 2017 14:58:42 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 103224 invoked by uid 89); 7 Dec 2017 14:58:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=ecs X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 07 Dec 2017 14:58:41 +0000 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 mx1.redhat.com (Postfix) with ESMTPS id D698C8008D; Thu, 7 Dec 2017 14:58:39 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 38C8460C54; Thu, 7 Dec 2017 14:58:39 +0000 (UTC) Subject: Re: Handling language trampoline To: Dmitry Antipov , gdb@sourceware.org References: <690fc1d3-9ba9-51ef-054d-9478993015a6@nvidia.com> From: Pedro Alves Message-ID: <7a5a19c6-c1bb-b67a-d302-a78ed8f001fa@redhat.com> Date: Thu, 07 Dec 2017 14:58:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <690fc1d3-9ba9-51ef-054d-9478993015a6@nvidia.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-12/txt/msg00006.txt.bz2 On 12/07/2017 02:21 PM, Dmitry Antipov wrote: > When debugging a program which is definitely in C++: > > (gdb) info source > [...skipped...] > Contains 66 lines. > Source language is c++. > Producer is clang version 6.0.0 (trunk 319884). > Compiled with DWARF 2 debugging format. > Does not include preprocessor macro info. > > I've noticed that 'step' command causes GDB to perform some > ObjC-specific work: ... > Why it is so if source language was recognized as C++? A program is often composed of sources written in different languages (C++, C, Asm, etc.). Plus, a trampoline itself has no symbol/language associated. > #0 lookup_minimal_symbol (name=0x8459a1 "_objc_msgSend", sfile=sfile@entry=0x0, objf=objf@entry=0x0) at ../../gdb/minsyms.c:313 > #1 0x00000000005bd0f9 in lookup_bound_minimal_symbol (name=) at ../../gdb/minsyms.c:432 > #2 0x00000000005c1666 in find_objc_msgsend () at ../../gdb/objc-lang.c:1282 > #3 find_objc_msgcall (pc=pc@entry=139646390853344, new_pc=0x7ffe10329598) at ../../gdb/objc-lang.c:1340 > #4 0x00000000005c1820 in objc_skip_trampoline (frame=0x16a0eb0, stop_pc=139646390853344) at ../../gdb/objc-lang.c:313 > #5 0x000000000059f1dc in skip_language_trampoline (frame=frame@entry=0x16a0eb0, pc=139646390853344) at ../../gdb/language.c:605 > #6 0x0000000000597129 in process_event_stop_test (ecs=ecs@entry=0x7ffe10329d10) at ../../gdb/infrun.c:6706 > #7 0x0000000000598a10 in handle_signal_stop (ecs=ecs@entry=0x7ffe10329d10) at ../../gdb/infrun.c:6163 Above, frame #4: /* Iterate through all registered languages looking for and calling any non-NULL struct language_defn.skip_trampoline() functions. Return the result from the first that returns non-zero, or 0 if all `fail'. */ CORE_ADDR skip_language_trampoline (struct frame_info *frame, CORE_ADDR pc) { for (const auto &lang : languages) { if (lang->skip_trampoline != NULL) { CORE_ADDR real_pc = lang->skip_trampoline (frame, pc); if (real_pc) return real_pc; } } return 0; } I don't offhand see how can GDB know which is the right language for the current PC the program just stopped at, and if the program stopped inside a trampoline. That's part of each language's skip_trampoline's job, so seems reasonable that GDB has to try them all. I'm guessing those minsym lookups showed up high in profile? I guess that could be solved with some per-objfile "minsym-of-_objc_msgSend" caching. Something like breakpoint.c:breakpoint_objfile_data. Thanks, Pedro Alves