This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Handling language trampoline
- From: Pedro Alves <palves at redhat dot com>
- To: Dmitry Antipov <dantipov at nvidia dot com>, gdb at sourceware dot org
- Date: Thu, 7 Dec 2017 14:58:38 +0000
- Subject: Re: Handling language trampoline
- Authentication-results: sourceware.org; auth=none
- References: <CAGDihekNnrW=JnVGuXHaPE6G3KPqxYBqwfCYhqSje_tFvCZztg@mail.gmail.com> <690fc1d3-9ba9-51ef-054d-9478993015a6@nvidia.com>
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=<optimized out>) 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