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

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

[Liang Cheng]

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

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

[Hui Zhu]

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
>

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

[Yao Qi]

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 (齐尧)

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

[Liang Cheng]

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 (齐尧)
>

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

[Yao Qi]

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 (齐尧)

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

[Liang Cheng]

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 (齐尧)
>

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

[Yao Qi]

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 (齐尧)

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

[Liang Cheng]

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 (齐尧)
>

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

[Liang Cheng]

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 (齐尧)
>>
>

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

[Yao Qi]

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 (齐尧)