* GDB 7.2 gets SIGSEGV when step into a function in a shared library
@ 2011-09-14 16:21 Liang Cheng
2011-09-15 5:46 ` Hui Zhu
2011-09-15 16:13 ` Yao Qi
0 siblings, 2 replies; 10+ messages in thread
From: Liang Cheng @ 2011-09-14 16:21 UTC (permalink / raw)
To: gdb
Hi,
The application and library under debug were built for ARM. The
target is running Android OS,
and the host is Linux X86 64. As long as we try to step into the
function xa_fun_in_lib, it would
cause segmentation fault in gdb. Same thing happened if step the instructions.
Here are the experiments I did for this issue, and some notes.
0/. Apparently the app is built into ARM instruction, and the lib is
built into Thumb instruction.
1/. The symbols of xa_fun_in_lib is good.
2./ If I set breakpoint at xa_fun_in_lib, I would be able to step into
the function once the breakpoint
is hit.
3/. In order to see which address it tries to access, I manually
changed the vPacket to use 's',
and stepped the instruction " 0x8630: ldr pc, [r12, #2820]!
; 0xb04". Also I added
some instrumentation code in gdbserver side
linux_low.c::linux_resume_one_lwp, as follows:
ptrace(PTRACE_GETREGS, lwpid_of(lwp), 0, (void *)&tmpBuf);
ptrace (step ? PTRACE_SINGLESTEP : PTRACE_CONT, lwpid_of (lwp), 0,
/* Coerce to a uintptr_t first to avoid potential gcc warning
of coercing an 8 byte integer to a 4 byte pointer. */
(PTRACE_ARG4_TYPE) (uintptr_t) signal);
retVal = ptrace(PTRACE_GETREGS, lwpid_of(lwp), 0, (void *)&tmpBuf);
Before ptrace(SINGLESTEP/CONT..) is called,
(gdb) x /32x &tmpBuf
0xbed9c8d0: 0x0000000a 0x80009a04 0x00000000 0x00000000
0xbed9c8e0: 0xbeaf6c58 0x00008d9c 0x00000001 0xbeaf6c40
0xbed9c8f0: 0x00000000 0x00000000 0x00000000 0x00000000
0xbed9c900: 0x00008630 0xbeaf6c38 0x00008d21
0x00008630 <---------this is the PC
after it is called,
(gdb) x /32x &tmpBuf
0xbed9c8d0: 0x0000000a 0x80009a04 0x00000000 0x00000000
0xbed9c8e0: 0xbeaf6c58 0x00008d9c 0x00000001 0xbeaf6c40
0xbed9c8f0: 0x00000000 0x00000000 0x00000000 0x00000000
0xbed9c900: 0x00009134 0xbeaf6c38 0x80003701
0x80483702 <---------this is the PC
It looks like PC gets messed up when executing the instruction at
0x8630. I don't know
this happens, or whether in this case registers dump are valid.
4/. If both app and library are built with ARM flag, which means both
app and lib would use ARM
instruction, I am not able step into the function too although 'step'
does not cause segmentation
fault. In this case, if I manipulate the vPacket (sent to gdbserver on
target) to use 's' instead of 'c',
it would be able to step into the function.
So far I am stuck because of no idea why PC gets messed up. Anyone
else the similar issue
when trying to debug function in library? And any input to how to
investigate gdb/gdbserver side
also is appreciated. (below some other information is dumped).
thanks
Liang
(gdb) disassemble /m 0x8d14
Dump of assembler code for function main:
....
286 z = xa_fun_in_lib(10);
=> 0x00008d18 <+84>: mov.w r0, #10
0x00008d1c <+88>: blx 0x8628
0x00008d20 <+92>: mov r3, r0
0x00008d22 <+94>: str r3, [r7, #44] ; 0x2c
(gdb) x /8i 0x8628
=> 0x8628: add r12, pc, #0
0x862c: add r12, r12, #0
0x8630: ldr pc, [r12, #2820]! ; 0xb04
<====== This line seems to cause the issue.
0x8634: andeq r0, r0, r0
(gdb) info register
....
sp 0xbee1fc48 0xbee1fc48
lr 0x8d21 36129
pc 0x8628 0x8628
cpsr 0x60000010 1610612752
(gdb) x /8xdwx 0x8630+0xb04
0x9134 <_GLOBAL_OFFSET_TABLE_+32>: 0x800036fd 0x00000000
0x00000000 0x00000000
0x9144 <__dso_handle+4>: 0x00000000 0x00000000
0x00000000 0x00000000
(gdb) info address xa_fun_in_lib
Symbol "xa_fun_in_lib(int)" is a function at address 0x800036fc.
(gdb) l xa_fun_in_lib
212 }
213 }
214
215
216 int xa_fun_in_lib(int x)
217 {
218 int y = 0;
219 int z = 3;
220
221 z = x + y + z*8;
(gdb) l
222 return z;
223 }
(gdb) x /32i 0x800036fc
0x800036fc <xa_fun_in_lib(int)>: push {r7}
0x800036fe <xa_fun_in_lib(int)+2>: sub sp, #20
0x80003700 <xa_fun_in_lib(int)+4>: add r7, sp, #0
0x80003702 <xa_fun_in_lib(int)+6>: str r0, [r7, #4]
0x80003704 <xa_fun_in_lib(int)+8>: mov.w r3, #0
0x80003708 <xa_fun_in_lib(int)+12>: str r3, [r7, #12]
0x8000370a <xa_fun_in_lib(int)+14>: mov.w r3, #3
0x8000370e <xa_fun_in_lib(int)+18>: str r3, [r7, #8]
0x80003710 <xa_fun_in_lib(int)+20>: ldr r2, [r7, #4]
0x80003712 <xa_fun_in_lib(int)+22>: ldr r3, [r7, #12]
0x80003714 <xa_fun_in_lib(int)+24>: adds r2, r2, r3
0x80003716 <xa_fun_in_lib(int)+26>: ldr r3, [r7, #8]
0x80003718 <xa_fun_in_lib(int)+28>: mov.w r3, r3, lsl #3
0x8000371c <xa_fun_in_lib(int)+32>: adds r3, r2, r3
0x8000371e <xa_fun_in_lib(int)+34>: str r3, [r7, #8]
0x80003720 <xa_fun_in_lib(int)+36>: ldr r3, [r7, #8]
0x80003722 <xa_fun_in_lib(int)+38>: mov r0, r3
0x80003724 <xa_fun_in_lib(int)+40>: add.w r7, r7, #20
0x80003728 <xa_fun_in_lib(int)+44>: mov sp, r7
0x8000372a <xa_fun_in_lib(int)+46>: pop {r7}
0x8000372c <xa_fun_in_lib(int)+48>: bx lr
0x8000372e: nop
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB 7.2 gets SIGSEGV when step into a function in a shared library
2011-09-14 16:21 GDB 7.2 gets SIGSEGV when step into a function in a shared library Liang Cheng
@ 2011-09-15 5:46 ` Hui Zhu
2011-09-15 16:13 ` Yao Qi
1 sibling, 0 replies; 10+ messages in thread
From: Hui Zhu @ 2011-09-15 5:46 UTC (permalink / raw)
To: Liang Cheng; +Cc: gdb
Try the trunk.
If you got trouble with built trunk.
Try https://code.google.com/p/gdbt/
Thanks,
Hui
On Thu, Sep 15, 2011 at 00:21, Liang Cheng <liang.cheng555@gmail.com> wrote:
> Hi,
>
> The application and library under debug were built for ARM. The
> target is running Android OS,
> and the host is Linux X86 64. As long as we try to step into the
> function xa_fun_in_lib, it would
> cause segmentation fault in gdb. Same thing happened if step the instructions.
>
> Here are the experiments I did for this issue, and some notes.
>
> 0/. Apparently the app is built into ARM instruction, and the lib is
> built into Thumb instruction.
> 1/. The symbols of xa_fun_in_lib is good.
> 2./ If I set breakpoint at xa_fun_in_lib, I would be able to step into
> the function once the breakpoint
> is hit.
> 3/. In order to see which address it tries to access, I manually
> changed the vPacket to use 's',
> and stepped the instruction " 0x8630: ldr pc, [r12, #2820]!
> ; 0xb04". Also I added
> some instrumentation code in gdbserver side
> linux_low.c::linux_resume_one_lwp, as follows:
>
> ptrace(PTRACE_GETREGS, lwpid_of(lwp), 0, (void *)&tmpBuf);
> ptrace (step ? PTRACE_SINGLESTEP : PTRACE_CONT, lwpid_of (lwp), 0,
> /* Coerce to a uintptr_t first to avoid potential gcc warning
> of coercing an 8 byte integer to a 4 byte pointer. */
> (PTRACE_ARG4_TYPE) (uintptr_t) signal);
>
> retVal = ptrace(PTRACE_GETREGS, lwpid_of(lwp), 0, (void *)&tmpBuf);
>
> Before ptrace(SINGLESTEP/CONT..) is called,
> (gdb) x /32x &tmpBuf
> 0xbed9c8d0: 0x0000000a 0x80009a04 0x00000000 0x00000000
> 0xbed9c8e0: 0xbeaf6c58 0x00008d9c 0x00000001 0xbeaf6c40
> 0xbed9c8f0: 0x00000000 0x00000000 0x00000000 0x00000000
> 0xbed9c900: 0x00008630 0xbeaf6c38 0x00008d21
> 0x00008630 <---------this is the PC
>
> after it is called,
> (gdb) x /32x &tmpBuf
> 0xbed9c8d0: 0x0000000a 0x80009a04 0x00000000 0x00000000
> 0xbed9c8e0: 0xbeaf6c58 0x00008d9c 0x00000001 0xbeaf6c40
> 0xbed9c8f0: 0x00000000 0x00000000 0x00000000 0x00000000
> 0xbed9c900: 0x00009134 0xbeaf6c38 0x80003701
> 0x80483702 <---------this is the PC
>
> It looks like PC gets messed up when executing the instruction at
> 0x8630. I don't know
> this happens, or whether in this case registers dump are valid.
>
> 4/. If both app and library are built with ARM flag, which means both
> app and lib would use ARM
> instruction, I am not able step into the function too although 'step'
> does not cause segmentation
> fault. In this case, if I manipulate the vPacket (sent to gdbserver on
> target) to use 's' instead of 'c',
> it would be able to step into the function.
>
> So far I am stuck because of no idea why PC gets messed up. Anyone
> else the similar issue
> when trying to debug function in library? And any input to how to
> investigate gdb/gdbserver side
> also is appreciated. (below some other information is dumped).
>
> thanks
> Liang
>
>
> (gdb) disassemble /m 0x8d14
> Dump of assembler code for function main:
> ....
> 286 z = xa_fun_in_lib(10);
> => 0x00008d18 <+84>: mov.w r0, #10
> 0x00008d1c <+88>: blx 0x8628
> 0x00008d20 <+92>: mov r3, r0
> 0x00008d22 <+94>: str r3, [r7, #44] ; 0x2c
>
> (gdb) x /8i 0x8628
> => 0x8628: add r12, pc, #0
> 0x862c: add r12, r12, #0
> 0x8630: ldr pc, [r12, #2820]! ; 0xb04
> <====== This line seems to cause the issue.
> 0x8634: andeq r0, r0, r0
> (gdb) info register
> ....
> sp 0xbee1fc48 0xbee1fc48
> lr 0x8d21 36129
> pc 0x8628 0x8628
> cpsr 0x60000010 1610612752
>
> (gdb) x /8xdwx 0x8630+0xb04
> 0x9134 <_GLOBAL_OFFSET_TABLE_+32>: 0x800036fd 0x00000000
> 0x00000000 0x00000000
> 0x9144 <__dso_handle+4>: 0x00000000 0x00000000
> 0x00000000 0x00000000
>
> (gdb) info address xa_fun_in_lib
> Symbol "xa_fun_in_lib(int)" is a function at address 0x800036fc.
>
> (gdb) l xa_fun_in_lib
> 212 }
> 213 }
> 214
> 215
> 216 int xa_fun_in_lib(int x)
> 217 {
> 218 int y = 0;
> 219 int z = 3;
> 220
> 221 z = x + y + z*8;
> (gdb) l
> 222 return z;
> 223 }
> (gdb) x /32i 0x800036fc
> 0x800036fc <xa_fun_in_lib(int)>: push {r7}
> 0x800036fe <xa_fun_in_lib(int)+2>: sub sp, #20
> 0x80003700 <xa_fun_in_lib(int)+4>: add r7, sp, #0
> 0x80003702 <xa_fun_in_lib(int)+6>: str r0, [r7, #4]
> 0x80003704 <xa_fun_in_lib(int)+8>: mov.w r3, #0
> 0x80003708 <xa_fun_in_lib(int)+12>: str r3, [r7, #12]
> 0x8000370a <xa_fun_in_lib(int)+14>: mov.w r3, #3
> 0x8000370e <xa_fun_in_lib(int)+18>: str r3, [r7, #8]
> 0x80003710 <xa_fun_in_lib(int)+20>: ldr r2, [r7, #4]
> 0x80003712 <xa_fun_in_lib(int)+22>: ldr r3, [r7, #12]
> 0x80003714 <xa_fun_in_lib(int)+24>: adds r2, r2, r3
> 0x80003716 <xa_fun_in_lib(int)+26>: ldr r3, [r7, #8]
> 0x80003718 <xa_fun_in_lib(int)+28>: mov.w r3, r3, lsl #3
> 0x8000371c <xa_fun_in_lib(int)+32>: adds r3, r2, r3
> 0x8000371e <xa_fun_in_lib(int)+34>: str r3, [r7, #8]
> 0x80003720 <xa_fun_in_lib(int)+36>: ldr r3, [r7, #8]
> 0x80003722 <xa_fun_in_lib(int)+38>: mov r0, r3
> 0x80003724 <xa_fun_in_lib(int)+40>: add.w r7, r7, #20
> 0x80003728 <xa_fun_in_lib(int)+44>: mov sp, r7
> 0x8000372a <xa_fun_in_lib(int)+46>: pop {r7}
> 0x8000372c <xa_fun_in_lib(int)+48>: bx lr
> 0x8000372e: nop
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB 7.2 gets SIGSEGV when step into a function in a shared library
2011-09-14 16:21 GDB 7.2 gets SIGSEGV when step into a function in a shared library Liang Cheng
2011-09-15 5:46 ` Hui Zhu
@ 2011-09-15 16:13 ` Yao Qi
2011-09-15 16:39 ` Liang Cheng
1 sibling, 1 reply; 10+ messages in thread
From: Yao Qi @ 2011-09-15 16:13 UTC (permalink / raw)
To: gdb
On 09/15/2011 12:21 AM, Liang Cheng wrote:
> Hi,
>
> The application and library under debug were built for ARM. The
> target is running Android OS,
> and the host is Linux X86 64. As long as we try to step into the
> function xa_fun_in_lib, it would
> cause segmentation fault in gdb. Same thing happened if step the instructions.
>
> Here are the experiments I did for this issue, and some notes.
>
If you are reporting a problem of gdb, please describe the problem as
clear as possible. A clean and simple debug session is helpful for
other people here to understand what is your problem. Please don't mix
the experiments or your work in the problem description.
>
> So far I am stuck because of no idea why PC gets messed up. Anyone
> else the similar issue
> when trying to debug function in library? And any input to how to
> investigate gdb/gdbserver side
> also is appreciated. (below some other information is dumped).
>
Due to lack of clear steps you did in gdb, and its output, I have no
idea what the problem is and how do you get to the problem, except for
some wild guess,
> (gdb) disassemble /m 0x8d14
> Dump of assembler code for function main:
> ....
> 286 z = xa_fun_in_lib(10);
> => 0x00008d18<+84>: mov.w r0, #10
> 0x00008d1c<+88>: blx 0x8628
> 0x00008d20<+92>: mov r3, r0
> 0x00008d22<+94>: str r3, [r7, #44] ; 0x2c
How do you get SIGSEGV from here? I guess you typed `step' try to step
into xa_fun_in_lib, but get a SIGSEGV afterwards.
Last but not least, as Hui suggested, please try GDB 7.3 release or GDB
CVS trunk.
--
Yao (é½å°§)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB 7.2 gets SIGSEGV when step into a function in a shared library
2011-09-15 16:13 ` Yao Qi
@ 2011-09-15 16:39 ` Liang Cheng
2011-09-16 13:55 ` Yao Qi
0 siblings, 1 reply; 10+ messages in thread
From: Liang Cheng @ 2011-09-15 16:39 UTC (permalink / raw)
To: Yao Qi; +Cc: gdb
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?
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
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:
>>
>> Hi,
>>
>> The application and library under debug were built for ARM. The
>> target is running Android OS,
>> and the host is Linux X86 64. As long as we try to step into the
>> function xa_fun_in_lib, it would
>> cause segmentation fault in gdb. Same thing happened if step the
>> instructions.
>>
>> Here are the experiments I did for this issue, and some notes.
>>
>
> If you are reporting a problem of gdb, please describe the problem as clear
> as possible. A clean and simple debug session is helpful for other people
> here to understand what is your problem. Please don't mix the experiments
> or your work in the problem description.
>
>>
>> So far I am stuck because of no idea why PC gets messed up. Anyone
>> else the similar issue
>> when trying to debug function in library? And any input to how to
>> investigate gdb/gdbserver side
>> also is appreciated. (below some other information is dumped).
>>
>
> Due to lack of clear steps you did in gdb, and its output, I have no idea
> what the problem is and how do you get to the problem, except for some wild
> guess,
>
>> (gdb) disassemble /m 0x8d14
>> Dump of assembler code for function main:
>> ....
>> 286 z = xa_fun_in_lib(10);
>> => 0x00008d18<+84>: mov.w r0, #10
>> 0x00008d1c<+88>: blx 0x8628
>> 0x00008d20<+92>: mov r3, r0
>> 0x00008d22<+94>: str r3, [r7, #44] ; 0x2c
>
> How do you get SIGSEGV from here? I guess you typed `step' try to step into
> xa_fun_in_lib, but get a SIGSEGV afterwards.
>
> Last but not least, as Hui suggested, please try GDB 7.3 release or GDB CVS
> trunk.
>
> --
> Yao (齐尧)
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB 7.2 gets SIGSEGV when step into a function in a shared library
2011-09-15 16:39 ` Liang Cheng
@ 2011-09-16 13:55 ` Yao Qi
[not found] ` <CAEU25CYOnYAdqO8ZjTVyUFf2uTHRv7OC6WKnFtGKWmjG4cdNgQ@mail.gmail.com>
0 siblings, 1 reply; 10+ messages in thread
From: Yao Qi @ 2011-09-16 13:55 UTC (permalink / raw)
To: Liang Cheng; +Cc: gdb
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 (é½å°§)
^ permalink raw reply [flat|nested] 10+ messages in thread
* GDB 7.2 gets SIGSEGV when step into a function in a shared library
[not found] ` <CAEU25CYOnYAdqO8ZjTVyUFf2uTHRv7OC6WKnFtGKWmjG4cdNgQ@mail.gmail.com>
@ 2011-09-16 20:04 ` Liang Cheng
2011-09-17 1:28 ` Yao Qi
0 siblings, 1 reply; 10+ messages in thread
From: Liang Cheng @ 2011-09-16 20:04 UTC (permalink / raw)
To: gdb; +Cc: yao
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.
Here is debug output. Next step is to try gdb trunk.
thanks
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
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 (齐尧)
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB 7.2 gets SIGSEGV when step into a function in a shared library
2011-09-16 20:04 ` Liang Cheng
@ 2011-09-17 1:28 ` Yao Qi
2011-09-19 15:57 ` Liang Cheng
0 siblings, 1 reply; 10+ messages in thread
From: Yao Qi @ 2011-09-17 1:28 UTC (permalink / raw)
To: Liang Cheng; +Cc: gdb
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 (é½å°§)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB 7.2 gets SIGSEGV when step into a function in a shared library
2011-09-17 1:28 ` Yao Qi
@ 2011-09-19 15:57 ` Liang Cheng
2011-09-19 22:18 ` Liang Cheng
0 siblings, 1 reply; 10+ messages in thread
From: Liang Cheng @ 2011-09-19 15:57 UTC (permalink / raw)
To: Yao Qi; +Cc: gdb
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 (齐尧)
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB 7.2 gets SIGSEGV when step into a function in a shared library
2011-09-19 15:57 ` Liang Cheng
@ 2011-09-19 22:18 ` Liang Cheng
2011-09-20 1:07 ` Yao Qi
0 siblings, 1 reply; 10+ messages in thread
From: Liang Cheng @ 2011-09-19 22:18 UTC (permalink / raw)
To: Yao Qi; +Cc: gdb
But it seems to close what I want. But the extension gets the PC
wrong, it should be 0x800036fd.
Why we use
nextpc = (CORE_ADDR)read_memory_integer ((CORE_ADDR) base,
4, byte_order);
instead of
nextpc = (CORE_ADDR)read_memory_unsigned integer
((CORE_ADDR) base,
4, byte_order);
in arm-tdep.c::arm_get_next_pc_raw? Below is the stack in debug session of gdb.
thanks
(gdb) c
Continuing.
Breakpoint 1, arm_get_next_pc (frame=0x40d9720, pc=34352) at arm-tdep.c:4854
4854 {
(gdb) bt
#0 arm_get_next_pc (frame=0x40d9720, pc=34352) at arm-tdep.c:4854
#1 0x0000000000431b0c in arm_linux_software_single_step
(frame=0x40d9720) at arm-linux-tdep.c:751
#2 0x00000000004d8321 in maybe_software_singlestep
(gdbarch=0x13cc920, pc=34352) at infrun.c:1577
#3 0x00000000004dabad in resume (step=1, sig=TARGET_SIGNAL_0) at infrun.c:1689
#4 0x00000000004dfbf0 in proceed (addr=<value optimized out>,
siggnal=TARGET_SIGNAL_DEFAULT, step=1) at infrun.c:2128
#5 0x00000000004d2227 in step_once (skip_subroutines=0,
single_inst=1, count=1, thread=-1) at infcmd.c:1046
#6 0x00000000004d40d4 in step_1 (skip_subroutines=0, single_inst=1,
count_string=0x0) at infcmd.c:894
(gdb) n
4857 if (arm_frame_is_thumb (frame))
(gdb) n
4866 if (nextpc == pc)
(gdb) p pc
$1 = 34352
(gdb) p /x pc
$2 = 0x8630
(gdb) p /x nextpc
$3 = 0xffffffff800036fd
On Mon, Sep 19, 2011 at 10:57 AM, Liang Cheng <liang.cheng555@gmail.com> wrote:
> 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 (齐尧)
>>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: GDB 7.2 gets SIGSEGV when step into a function in a shared library
2011-09-19 22:18 ` Liang Cheng
@ 2011-09-20 1:07 ` Yao Qi
0 siblings, 0 replies; 10+ messages in thread
From: Yao Qi @ 2011-09-20 1:07 UTC (permalink / raw)
To: Liang Cheng; +Cc: gdb
On 09/20/2011 06:17 AM, Liang Cheng wrote:
> But it seems to close what I want. But the extension gets the PC
> wrong, it should be 0x800036fd.
> Why we use
> nextpc = (CORE_ADDR)read_memory_integer ((CORE_ADDR) base,
> 4, byte_order);
> instead of
> nextpc = (CORE_ADDR)read_memory_unsigned integer
> ((CORE_ADDR) base,
> 4, byte_order);
> in arm-tdep.c::arm_get_next_pc_raw? Below is the stack in debug session of gdb.
>
Thanks for your analysis. We should use read_memory_unsigned_interger
here, IMO.
> (gdb) c
> Continuing.
>
> Breakpoint 1, arm_get_next_pc (frame=0x40d9720, pc=34352) at arm-tdep.c:4854
> 4854 {
> (gdb) bt
> #0 arm_get_next_pc (frame=0x40d9720, pc=34352) at arm-tdep.c:4854
> #1 0x0000000000431b0c in arm_linux_software_single_step
> (frame=0x40d9720) at arm-linux-tdep.c:751
> #2 0x00000000004d8321 in maybe_software_singlestep
> (gdbarch=0x13cc920, pc=34352) at infrun.c:1577
> #3 0x00000000004dabad in resume (step=1, sig=TARGET_SIGNAL_0) at infrun.c:1689
> #4 0x00000000004dfbf0 in proceed (addr=<value optimized out>,
> siggnal=TARGET_SIGNAL_DEFAULT, step=1) at infrun.c:2128
> #5 0x00000000004d2227 in step_once (skip_subroutines=0,
> single_inst=1, count=1, thread=-1) at infcmd.c:1046
> #6 0x00000000004d40d4 in step_1 (skip_subroutines=0, single_inst=1,
> count_string=0x0) at infcmd.c:894
>
> (gdb) n
> 4857 if (arm_frame_is_thumb (frame))
> (gdb) n
> 4866 if (nextpc == pc)
> (gdb) p pc
> $1 = 34352
> (gdb) p /x pc
> $2 = 0x8630
> (gdb) p /x nextpc
> $3 = 0xffffffff800036fd
>
The value of nextpc here may explain why inferior stops at the point of
returning from xa_fun_in_lib, rather than the entry of it.
On 09/19/2011 11:57 PM, Liang Cheng wrote:
> infrun: stop_pc = 0x8630
0x8630: ldr pc, [r12, #2820]!
inferior will go to 0x800036fc.
> 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
However, inferior stops at 0x8d20,
0x00008d1c <+88>: blx 0x8628
0x00008d20 <+92>: mov r3, r0
The reason for this symptom is gdb will insert software single-step
breakpoint at function return address (value of LR register) if the
next_pc is greater than 0xffff0000, as the following code shows
static int
arm_linux_software_single_step (struct frame_info *frame)
{
struct gdbarch *gdbarch = get_frame_arch (frame);
struct address_space *aspace = get_frame_address_space (frame);
CORE_ADDR next_pc = arm_get_next_pc (frame, get_frame_pc (frame));
/* The Linux kernel offers some user-mode helpers in a high page. We can
not read this page (as of 2.6.23), and even if we could then we
couldn't
set breakpoints in it, and even if we could then the atomic operations
would fail when interrupted. They are all called as functions and
return
to the address in LR, so step to there instead. */
if (next_pc > 0xffff0000)
next_pc = get_frame_register_unsigned (frame, ARM_LR_REGNUM);
arm_insert_single_step_breakpoint (gdbarch, aspace, next_pc);
return 1;
}
--
Yao (é½å°§)
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-09-20 1:07 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-14 16:21 GDB 7.2 gets SIGSEGV when step into a function in a shared library Liang Cheng
2011-09-15 5:46 ` Hui Zhu
2011-09-15 16:13 ` Yao Qi
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
2011-09-19 22:18 ` Liang Cheng
2011-09-20 1:07 ` Yao Qi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).