From: Liang Cheng <liang.cheng555@gmail.com>
To: Yao Qi <yao@codesourcery.com>
Cc: gdb@sourceware.org
Subject: Re: GDB 7.2 gets SIGSEGV when step into a function in a shared library
Date: Mon, 19 Sep 2011 15:57:00 -0000 [thread overview]
Message-ID: <CAEU25CZwSJnmMe88UkibOoviwGANCB-f3k1swbeHP-+iBZbDfQ@mail.gmail.com> (raw)
In-Reply-To: <4E73F7B7.9070800@codesourcery.com>
Oh.. I just put too much focus on gdb server side.. ;)
Built a gdb from gdb 7.3.1 source, although it behaves better (no
segmentation fault), stepping
is still not right yet.
(gdb) n
286 z = xa_fun_in_lib(10);
(gdb) set debug infrun 1
(gdb) show debug infrun
Inferior debugging is 1.
(gdb) s
infrun: clear_proceed_status_thread (Thread 1874.1874)
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: 1874 [Thread 1874.1874],
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 1874.1874
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: 1874 [Thread 1874.1874],
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 1874.1874
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: 1874 [Thread 1874.1874],
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 1874.1874
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: 1874 [Thread 1874.1874],
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 1874.1874
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: 1874 [Thread 1874.1874],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x8d20
infrun: software single step trap for Thread 1874.1874
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: 1874 [Thread 1874.1874],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x8d22
infrun: software single step trap for Thread 1874.1874
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: 1874 [Thread 1874.1874],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x8d24
infrun: software single step trap for Thread 1874.1874
infrun: stepped to a different line
infrun: stop_stepping
289 res = (*engine)->Realize(engine, XA_BOOLEAN_FALSE);
(gdb) display /i $pc
1: x/i $pc
=> 0x8d24 <main+96>: ldr r3, [r7, #48] ; 0x30
(gdb) info address xa_fun_in_lib
Symbol "xa_fun_in_lib(int)" is a function at address 0x800036fc.
On Fri, Sep 16, 2011 at 8:28 PM, Yao Qi <yao@codesourcery.com> wrote:
> 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 (齐尧)
>
next prev parent reply other threads:[~2011-09-19 15:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-14 16:21 Liang Cheng
2011-09-15 5:46 ` Hui Zhu
[not found] ` <4E72241F.5060402@codesourcery.com>
2011-09-15 16:39 ` Liang Cheng
2011-09-16 13:55 ` Yao Qi
[not found] ` <CAEU25CYOnYAdqO8ZjTVyUFf2uTHRv7OC6WKnFtGKWmjG4cdNgQ@mail.gmail.com>
2011-09-16 20:04 ` Liang Cheng
2011-09-17 1:28 ` Yao Qi
2011-09-19 15:57 ` Liang Cheng [this message]
2011-09-19 22:18 ` Liang Cheng
2011-09-20 1:07 ` Yao Qi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAEU25CZwSJnmMe88UkibOoviwGANCB-f3k1swbeHP-+iBZbDfQ@mail.gmail.com \
--to=liang.cheng555@gmail.com \
--cc=gdb@sourceware.org \
--cc=yao@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox