* 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
[parent not found: <CAEU25CYOnYAdqO8ZjTVyUFf2uTHRv7OC6WKnFtGKWmjG4cdNgQ@mail.gmail.com>]
* 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).