Re: GDB 7.2 gets SIGSEGV when step into a function in a shared library

[Hui Zhu <teawater at gmail dot com>]

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
>