This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GDB 7.2 gets SIGSEGV when step into a function in a shared library
On 09/17/2011 04:03 AM, Liang Cheng wrote:
> Yao/Hui,
>
> Built a gdbserver based on gdb 7.3.1, and I get the exactly same error.
> The gdb that I used is arm-eabi-4.4.3.
>
You may misunderstand my point. I suggest that you build recent gdb
instead of gdbserver. AFAICS, this problem is related to gdb, rather
than gdbserver.
"arm-eabi-4.4.3" is not a right version of gdb.
> Here is debug output. Next step is to try gdb trunk.
Please build gdb from gdb trunk.
>
> Breakpoint 1, main (argc=1, argv=0xbed00cb4) at vendor/altestavplayback.c:284
> 284 CheckErr(res);
> 1: x/i $pc
> => 0x8d12 <main+78>: ldr r0, [r7, #52] ; 0x34
> (gdb) n
> 286 z = xa_fun_in_lib(10);
> 1: x/i $pc
> => 0x8d18 <main+84>: mov.w r0, #10
> (gdb) set debug infrun 1
> (gdb) show debug infrun
> Inferior debugging is 1.
> (gdb) s
> infrun: clear_proceed_status_thread (Thread 746.746)
> infrun: proceed (addr=0xffffffff, signal=144, step=1)
> infrun: resume (step=1, signal=0), trap_expected=0
> infrun: wait_for_inferior (treat_exec_as_sigtrap=0)
> infrun: target_wait (-1, status) =
> infrun: 746 [Thread 746.746],
> infrun: status->kind = stopped, signal = SIGTRAP
> infrun: infwait_normal_state
> infrun: TARGET_WAITKIND_STOPPED
> infrun: stop_pc = 0x8d1c
> infrun: software single step trap for Thread 746.746
> infrun: stepping inside range [0x8d18-0x8d24]
> infrun: resume (step=1, signal=0), trap_expected=0
> infrun: prepare_to_wait
> infrun: target_wait (-1, status) =
> infrun: 746 [Thread 746.746],
> infrun: status->kind = stopped, signal = SIGTRAP
> infrun: infwait_normal_state
> infrun: TARGET_WAITKIND_STOPPED
> infrun: stop_pc = 0x8628
> infrun: software single step trap for Thread 746.746
> infrun: stepped into dynsym resolve code
> infrun: resume (step=1, signal=0), trap_expected=0
> infrun: prepare_to_wait
> infrun: target_wait (-1, status) =
> infrun: 746 [Thread 746.746],
> infrun: status->kind = stopped, signal = SIGTRAP
> infrun: infwait_normal_state
> infrun: TARGET_WAITKIND_STOPPED
> infrun: stop_pc = 0x862c
> infrun: software single step trap for Thread 746.746
> infrun: stepped into dynsym resolve code
> infrun: resume (step=1, signal=0), trap_expected=0
> infrun: prepare_to_wait
> infrun: target_wait (-1, status) =
> infrun: 746 [Thread 746.746],
> infrun: status->kind = stopped, signal = SIGTRAP
> infrun: infwait_normal_state
> infrun: TARGET_WAITKIND_STOPPED
> infrun: stop_pc = 0x8630
> infrun: software single step trap for Thread 746.746
> infrun: stepped into dynsym resolve code
> infrun: resume (step=1, signal=0), trap_expected=0
GDB is trying to single step this instruction,
0x8630: ldr pc, [r12, #2820]! ; 0xb04
at this point, GDB will compute the "next pc" of this instruction, and
set breakpoint on that address. GDB 7.2 can (or should) compute the
"next pc" correctly, but may not set single-step breakpoint correctly
for correct execution state.
Ulrich had a patch to address this issue, which might be the cause of
your problem.
[rfc, arm] Always use correct execution state for single-step breakpoints
http://sourceware.org/ml/gdb-patches/2011-03/msg01077.html
This patch should be in 7.3.1. If my assumption above is correct, using
gdb 7.3.1 or cvs trunk should fix your problem.
> infrun: prepare_to_wait
> infrun: target_wait (-1, status) =
> infrun: 746 [Thread 746.746],
> infrun: status->kind = stopped, signal = SIGSEGV
> infrun: infwait_normal_state
> infrun: TARGET_WAITKIND_STOPPED
> infrun: stop_pc = 0x8d22
> infrun: random signal 11
>
> Program received signal SIGSEGV, Segmentation fault.
> infrun: stop_stepping
> 0x00008d22 in main (argc=1, argv=0xbed00cb4) at vendor/altestavplayback.c:286
> 286 z = xa_fun_in_lib(10);
> 1: x/i $pc
> => 0x8d22 <main+94>: str r3, [r7, #44] ; 0x2c
>
> On Fri, Sep 16, 2011 at 8:55 AM, Yao Qi <yao@codesourcery.com> wrote:
>> On 09/16/2011 12:39 AM, Liang Cheng wrote:
>>> Sorry for not being clear.
>>> Here is the debug session getting SIGSEGV. xa_fun_in_lib is the
>>> function defined in shared library, and its symbols has been found by
>>> gdb. Step instruction also caused the same issue. The reason that I
>>> attach those disassemble dump is to avoid rounds of ask-give. Let me
>>> know if disassemble of the piece of code is needed. Any idea of why
>>> it happens?
>>>
>>
>> This debug session is much clear than last one. Thanks.
>>
>>> Breakpoint 1, main (argc=1, argv=0xbef25ca4) at vendor/altestavplayback.c:284
>>> 284 CheckErr(res);
>>> 3: x/i $pc
>>> => 0x8d12 <main+78>: ldr r0, [r7, #52] ; 0x34
>>> (gdb) n
>>> 286 z = xa_fun_in_lib(10);
>>> 3: x/i $pc
>>> => 0x8d18 <main+84>: mov.w r0, #10
>>> (gdb) s
>>>
>>
>> Before you run `step', turn on some debug output first. Like this `set
>> debug infrun 1'. Then, when you run `step', you can see some debug
>> output, which will show how PC is changed and events inferior gets
>> during command `step'.
>>
>> However, before we go into the details of debug output, could you check
>> whether GDB cvs trunk works or not. You just have to build gdb for arm,
>> and I think GDB cvs trunk should be able to work with your 7.2 gdbserver.
>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x00008d22 in main (argc=1, argv=0xbef25ca4) at vendor/altestavplayback.c:286
>>> 286 z = xa_fun_in_lib(10);
>>> 3: x/i $pc
>>> => 0x8d22 <main+94>: str r3, [r7, #44] ; 0x2c
>>> (gdb) info address xa_fun_in_lib
>>> Symbol "xa_fun_in_lib(int)" is a function at address 0x800036fc.
>>>
>>> On Thu, Sep 15, 2011 at 11:13 AM, Yao Qi <yao@codesourcery.com> wrote:
>>>> On 09/15/2011 12:21 AM, Liang Cheng wrote:
--
Yao (éå)