* gdb command "next" wrongly working as command "step" @ 2019-08-18 3:36 William Tambe 2019-08-18 4:16 ` Jan Kratochvil 0 siblings, 1 reply; 11+ messages in thread From: William Tambe @ 2019-08-18 3:36 UTC (permalink / raw) To: gdb I having an issue where the gdb command "next" wrongly work as the command "step", in that it will step-into functions instead of stepping-over functions. To support single stepping I have implemnted set_gdbarch_software_single_step(). Is there another function that I need to implement to support stepping-over functions ? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: gdb command "next" wrongly working as command "step" 2019-08-18 3:36 gdb command "next" wrongly working as command "step" William Tambe @ 2019-08-18 4:16 ` Jan Kratochvil 2019-08-18 8:32 ` William Tambe 0 siblings, 1 reply; 11+ messages in thread From: Jan Kratochvil @ 2019-08-18 4:16 UTC (permalink / raw) To: William Tambe; +Cc: gdb On Sun, 18 Aug 2019 05:36:34 +0200, William Tambe wrote: > I having an issue where the gdb command "next" wrongly work as the > command "step", in that it will step-into functions instead of > stepping-over functions. > > To support single stepping I have implemnted set_gdbarch_software_single_step(). > > Is there another function that I need to implement to support > stepping-over functions ? "next" needs properly implemented backtrace/unwinding so that can it can do "finish" when "next" detects it stepped into a function. Jan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: gdb command "next" wrongly working as command "step" 2019-08-18 4:16 ` Jan Kratochvil @ 2019-08-18 8:32 ` William Tambe 2019-08-18 9:06 ` Jan Kratochvil 0 siblings, 1 reply; 11+ messages in thread From: William Tambe @ 2019-08-18 8:32 UTC (permalink / raw) To: Jan Kratochvil; +Cc: gdb On Sat, Aug 17, 2019 at 11:16 PM Jan Kratochvil <jan.kratochvil@redhat.com> wrote: > > On Sun, 18 Aug 2019 05:36:34 +0200, William Tambe wrote: > > I having an issue where the gdb command "next" wrongly work as the > > command "step", in that it will step-into functions instead of > > stepping-over functions. > > > > To support single stepping I have implemnted set_gdbarch_software_single_step(). > > > > Is there another function that I need to implement to support > > stepping-over functions ? > > "next" needs properly implemented backtrace/unwinding so that can it can do > "finish" when "next" detects it stepped into a function. Can I have suggestions of locations within the gdb code where I could put breakpoints to trace where the issue I am having is occurring ? Alternatively, what function within the gdb code implement "next" and "finish" ? > > > Jan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: gdb command "next" wrongly working as command "step" 2019-08-18 8:32 ` William Tambe @ 2019-08-18 9:06 ` Jan Kratochvil 2019-08-23 21:33 ` William Tambe 0 siblings, 1 reply; 11+ messages in thread From: Jan Kratochvil @ 2019-08-18 9:06 UTC (permalink / raw) To: William Tambe; +Cc: gdb On Sun, 18 Aug 2019 10:31:54 +0200, William Tambe wrote: > Can I have suggestions of locations within the gdb code where I could > put breakpoints to trace where the issue I am having is occurring ? Check what "set debug infrun 1" says and grep the sources for the displayed messages. Jan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: gdb command "next" wrongly working as command "step" 2019-08-18 9:06 ` Jan Kratochvil @ 2019-08-23 21:33 ` William Tambe 2019-08-23 21:54 ` Pedro Alves 0 siblings, 1 reply; 11+ messages in thread From: William Tambe @ 2019-08-23 21:33 UTC (permalink / raw) To: Jan Kratochvil; +Cc: gdb On Sun, Aug 18, 2019 at 4:06 AM Jan Kratochvil <jan.kratochvil@redhat.com> wrote: > > On Sun, 18 Aug 2019 10:31:54 +0200, William Tambe wrote: > > Can I have suggestions of locations within the gdb code where I could > > put breakpoints to trace where the issue I am having is occurring ? > > Check what "set debug infrun 1" says and grep the sources for the displayed > messages. > Using "set debug infrun 1", I can see that GDB stops only after printing the following message: infrun: stepped to a different line. When the above event happens, GDB has stepped inside the function, which is obviously going to be on a different line; however, I am expecting GDB to step over the function. Within the single-step function gdbarch_software_single_step_ftype() is there a way to tell whether GDB is stepping-into or stepping-over a function ? In fact within my implementation of gdbarch_software_single_step_ftype() when the instruction jump-and-link (used when calling a function) is decoded, the breakpoint is placed at the jump target; I could instead place the breakpoint after the instruction jump-and-link if I could tell whether the GDB command "step"/"stepi" or "next"/"nexti" was used. So within gdbarch_software_single_step_ftype(), is there a way to tell whether GDB is stepping-into or stepping-over a function ? > > Jan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: gdb command "next" wrongly working as command "step" 2019-08-23 21:33 ` William Tambe @ 2019-08-23 21:54 ` Pedro Alves 2019-08-24 3:36 ` William Tambe 0 siblings, 1 reply; 11+ messages in thread From: Pedro Alves @ 2019-08-23 21:54 UTC (permalink / raw) To: William Tambe, Jan Kratochvil; +Cc: gdb On 8/23/19 10:33 PM, William Tambe wrote: > On Sun, Aug 18, 2019 at 4:06 AM Jan Kratochvil > <jan.kratochvil@redhat.com> wrote: >> On Sun, 18 Aug 2019 10:31:54 +0200, William Tambe wrote: >>> Can I have suggestions of locations within the gdb code where I could >>> put breakpoints to trace where the issue I am having is occurring ? >> Check what "set debug infrun 1" says and grep the sources for the displayed >> messages. >> > Using "set debug infrun 1", I can see that GDB stops only after > printing the following message: > infrun: stepped to a different line. > When the above event happens, GDB has stepped inside the function, > which is obviously going to be on a different line; however, I am > expecting GDB to step over the function. Do a backtrace at this point. GDB should see the caller in frame #1. Sounds like it doesn't. Or to be more accurate, use "stepi" to step to the first instruction of the called function, and run "bt" there. As Jan said, for "next" to work properly, backtrace/unwinding must work properly. When "next" behaves like "step", the most frequent reason is that unwinding is broken. "next" does a "backtrace" to detect whether you've stepped into called function, and if you did, then it continues execution to the address where the called function returns. Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: gdb command "next" wrongly working as command "step" 2019-08-23 21:54 ` Pedro Alves @ 2019-08-24 3:36 ` William Tambe 2019-08-25 19:04 ` William Tambe 0 siblings, 1 reply; 11+ messages in thread From: William Tambe @ 2019-08-24 3:36 UTC (permalink / raw) To: Pedro Alves; +Cc: Jan Kratochvil, gdb On Fri, Aug 23, 2019 at 4:54 PM Pedro Alves <palves@redhat.com> wrote: > > On 8/23/19 10:33 PM, William Tambe wrote: > > On Sun, Aug 18, 2019 at 4:06 AM Jan Kratochvil > > <jan.kratochvil@redhat.com> wrote: > >> On Sun, 18 Aug 2019 10:31:54 +0200, William Tambe wrote: > >>> Can I have suggestions of locations within the gdb code where I could > >>> put breakpoints to trace where the issue I am having is occurring ? > >> Check what "set debug infrun 1" says and grep the sources for the displayed > >> messages. > >> > > Using "set debug infrun 1", I can see that GDB stops only after > > printing the following message: > > infrun: stepped to a different line. > > When the above event happens, GDB has stepped inside the function, > > which is obviously going to be on a different line; however, I am > > expecting GDB to step over the function. > > Do a backtrace at this point. GDB should see the caller in frame #1. > Sounds like it doesn't. It does. My backtrace appear to be working properly. See below example listing from using "next" at a line where a function is used; it also show the output of "bt" before and after using "next". The decoded instructions is a lot of noise, but I am hoping you could see that I have a working backtracing, but yet "next" is working as though it was "step". (gdb) b _puts_r Breakpoint 1 at 0x1688: file ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c, line 73. (gdb) r Starting program: a.out Breakpoint 1, _puts_r (ptr=0x8b48 <impure_data>, s=0x7b20 "Hello World") at ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:73 73 size_t c = strlen (s); c7 2e => 0x00001688 <_puts_r+24>: cpy %2, %fp 9f 2c 0x0000168a <_puts_r+26>: inc8 %2, -4 8c 18 0x0000168c <_puts_r+28>: li8 %1, 0xc8 # -56 b8 1e 0x0000168e <_puts_r+30>: add %1, %fp f2 21 0x00001690 <_puts_r+32>: st32 %2, %1 c7 1e 0x00001692 <_puts_r+34>: cpy %1, %fp 9c 1c 0x00001694 <_puts_r+36>: inc8 %1, -52 ea 11 0x00001696 <_puts_r+38>: ld32 %1, %1 e0 d0 0x00001698 <_puts_r+40>: gip %sr a2 d0 be 01 00 00 0x0000169a <_puts_r+42>: inc32 %sr, 446 d8 fd 0x000016a0 <_puts_r+48>: jl %rp, %sr 8c 38 0x000016a2 <_puts_r+50>: li8 %3, 0xc8 # -56 b8 3e 0x000016a4 <_puts_r+52>: add %3, %fp ea 33 0x000016a6 <_puts_r+54>: ld32 %3, %3 f2 13 0x000016a8 <_puts_r+56>: st32 %1, %3 (gdb) bt #0 _puts_r (ptr=0x8b48 <impure_data>, s=0x7b20 "Hello World") at ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:73 #1 0x0000184a in puts (s=0x7b20 "Hello World") at ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:129 #2 0x0000132e in main (argc=1, argv=0x3fff000) at helloworld.c:5 (gdb) n strlen (str=0x7b20 "Hello World") at ../../../../../newlib-cygwin/newlib/libc/string/strlen.c:54 54 const char *start = str; c7 1e => 0x00001866 <strlen+14>: cpy %1, %fp 9f 18 0x00001868 <strlen+16>: inc8 %1, -8 c7 2e 0x0000186a <strlen+18>: cpy %2, %fp 9f 24 0x0000186c <strlen+20>: inc8 %2, -12 ea 32 0x0000186e <strlen+22>: ld32 %3, %2 f2 31 0x00001870 <strlen+24>: st32 %3, %1 (gdb) bt #0 strlen (str=0x7b20 "Hello World") at ../../../../../newlib-cygwin/newlib/libc/string/strlen.c:54 #1 0x000016a2 in _puts_r (ptr=0x8b48 <impure_data>, s=0x7b20 "Hello World") at ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:73 #2 0x0000184a in puts (s=0x7b20 "Hello World") at ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:129 #3 0x0000132e in main (argc=1, argv=0x3fff000) at helloworld.c:5 (gdb) > > Or to be more accurate, use "stepi" to step to the first instruction > of the called function, and run "bt" there. I have also tried using "stepi" to step to the first instruction of the called function. "bt" works correctly. > > As Jan said, for "next" to work properly, backtrace/unwinding must work > properly. When "next" behaves like "step", the most frequent reason > is that unwinding is broken. "next" does a "backtrace" to detect whether > you've stepped into called function, and if you did, then it continues > execution to the address where the called function returns. > > Thanks, > Pedro Alves ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: gdb command "next" wrongly working as command "step" 2019-08-24 3:36 ` William Tambe @ 2019-08-25 19:04 ` William Tambe 2019-08-26 13:18 ` Pedro Alves 0 siblings, 1 reply; 11+ messages in thread From: William Tambe @ 2019-08-25 19:04 UTC (permalink / raw) To: Pedro Alves; +Cc: Jan Kratochvil, gdb Please see below, less noisy GDB output showing a working backtrace where I can see the caller in frame #1; but yet GDB command "next" is working as though it was "step"; any suggestion where else I could look ? (gdb) b _puts_r Breakpoint 1 at 0x1688: file ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c, line 73. (gdb) r Starting program: a.out Breakpoint 1, _puts_r (ptr=0x8b48 <impure_data>, s=0x7b20 "Hello World") at ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:73 73 size_t c = strlen (s); (gdb) bt #0 _puts_r (ptr=0x8b48 <impure_data>, s=0x7b20 "Hello World") at ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:73 #1 0x0000184a in puts (s=0x7b20 "Hello World") at ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:129 #2 0x0000132e in main (argc=1, argv=0x3fff000) at helloworld.c:5 (gdb) n strlen (str=0x7b20 "Hello World") at ../../../../../newlib-cygwin/newlib/libc/string/strlen.c:54 54 const char *start = str; (gdb) bt #0 strlen (str=0x7b20 "Hello World") at ../../../../../newlib-cygwin/newlib/libc/string/strlen.c:54 #1 0x000016a2 in _puts_r (ptr=0x8b48 <impure_data>, s=0x7b20 "Hello World") at ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:73 #2 0x0000184a in puts (s=0x7b20 "Hello World") at ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:129 #3 0x0000132e in main (argc=1, argv=0x3fff000) at helloworld.c:5 On Fri, Aug 23, 2019 at 10:36 PM William Tambe <tambewilliam@gmail.com> wrote: > > On Fri, Aug 23, 2019 at 4:54 PM Pedro Alves <palves@redhat.com> wrote: > > > > On 8/23/19 10:33 PM, William Tambe wrote: > > > On Sun, Aug 18, 2019 at 4:06 AM Jan Kratochvil > > > <jan.kratochvil@redhat.com> wrote: > > >> On Sun, 18 Aug 2019 10:31:54 +0200, William Tambe wrote: > > >>> Can I have suggestions of locations within the gdb code where I could > > >>> put breakpoints to trace where the issue I am having is occurring ? > > >> Check what "set debug infrun 1" says and grep the sources for the displayed > > >> messages. > > >> > > > Using "set debug infrun 1", I can see that GDB stops only after > > > printing the following message: > > > infrun: stepped to a different line. > > > When the above event happens, GDB has stepped inside the function, > > > which is obviously going to be on a different line; however, I am > > > expecting GDB to step over the function. > > > > Do a backtrace at this point. GDB should see the caller in frame #1. > > Sounds like it doesn't. > > It does. > > My backtrace appear to be working properly. > See below example listing from using "next" at a line where a function > is used; it also show the output of "bt" before and after using > "next". > The decoded instructions is a lot of noise, but I am hoping you could > see that I have a working backtracing, but yet "next" is working as > though it was "step". > > (gdb) b _puts_r > Breakpoint 1 at 0x1688: file > ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c, line 73. > (gdb) r > Starting program: a.out > > Breakpoint 1, _puts_r (ptr=0x8b48 <impure_data>, s=0x7b20 "Hello > World") at ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:73 > 73 size_t c = strlen (s); > c7 2e => 0x00001688 <_puts_r+24>: cpy %2, %fp > 9f 2c 0x0000168a <_puts_r+26>: inc8 %2, -4 > 8c 18 0x0000168c <_puts_r+28>: li8 %1, 0xc8 # -56 > b8 1e 0x0000168e <_puts_r+30>: add %1, %fp > f2 21 0x00001690 <_puts_r+32>: st32 %2, %1 > c7 1e 0x00001692 <_puts_r+34>: cpy %1, %fp > 9c 1c 0x00001694 <_puts_r+36>: inc8 %1, -52 > ea 11 0x00001696 <_puts_r+38>: ld32 %1, %1 > e0 d0 0x00001698 <_puts_r+40>: gip %sr > a2 d0 be 01 00 00 0x0000169a <_puts_r+42>: inc32 %sr, 446 > d8 fd 0x000016a0 <_puts_r+48>: jl %rp, %sr > 8c 38 0x000016a2 <_puts_r+50>: li8 %3, 0xc8 # -56 > b8 3e 0x000016a4 <_puts_r+52>: add %3, %fp > ea 33 0x000016a6 <_puts_r+54>: ld32 %3, %3 > f2 13 0x000016a8 <_puts_r+56>: st32 %1, %3 > (gdb) bt > #0 _puts_r (ptr=0x8b48 <impure_data>, s=0x7b20 "Hello World") at > ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:73 > #1 0x0000184a in puts (s=0x7b20 "Hello World") at > ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:129 > #2 0x0000132e in main (argc=1, argv=0x3fff000) at helloworld.c:5 > (gdb) n > strlen (str=0x7b20 "Hello World") at > ../../../../../newlib-cygwin/newlib/libc/string/strlen.c:54 > 54 const char *start = str; > c7 1e => 0x00001866 <strlen+14>: cpy %1, %fp > 9f 18 0x00001868 <strlen+16>: inc8 %1, -8 > c7 2e 0x0000186a <strlen+18>: cpy %2, %fp > 9f 24 0x0000186c <strlen+20>: inc8 %2, -12 > ea 32 0x0000186e <strlen+22>: ld32 %3, %2 > f2 31 0x00001870 <strlen+24>: st32 %3, %1 > (gdb) bt > #0 strlen (str=0x7b20 "Hello World") at > ../../../../../newlib-cygwin/newlib/libc/string/strlen.c:54 > #1 0x000016a2 in _puts_r (ptr=0x8b48 <impure_data>, s=0x7b20 "Hello > World") at ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:73 > #2 0x0000184a in puts (s=0x7b20 "Hello World") at > ../../../../../newlib-cygwin/newlib/libc/stdio/puts.c:129 > #3 0x0000132e in main (argc=1, argv=0x3fff000) at helloworld.c:5 > (gdb) > > > > > > Or to be more accurate, use "stepi" to step to the first instruction > > of the called function, and run "bt" there. > > I have also tried using "stepi" to step to the first instruction of > the called function. > "bt" works correctly. > > > > > As Jan said, for "next" to work properly, backtrace/unwinding must work > > properly. When "next" behaves like "step", the most frequent reason > > is that unwinding is broken. "next" does a "backtrace" to detect whether > > you've stepped into called function, and if you did, then it continues > > execution to the address where the called function returns. > > > > Thanks, > > Pedro Alves ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: gdb command "next" wrongly working as command "step" 2019-08-25 19:04 ` William Tambe @ 2019-08-26 13:18 ` Pedro Alves 2019-09-01 19:06 ` William Tambe 0 siblings, 1 reply; 11+ messages in thread From: Pedro Alves @ 2019-08-26 13:18 UTC (permalink / raw) To: William Tambe; +Cc: Jan Kratochvil, gdb On 8/25/19 8:04 PM, William Tambe wrote: > Please see below, less noisy GDB output showing a working backtrace > where I can see the caller in frame #1; but yet GDB command "next" is > working as though it was "step"; any suggestion where else I could > look ? - You'll just have to debug gdb. Try to figure out why this code, inside the "infrun: stepped into subroutine" block,seemingly isn't being reached: /* Set a breakpoint at callee's return address (the address at which the caller will resume). */ insert_step_resume_breakpoint_at_caller (frame); - I'd use "nexti" instead of "next" to try stepping over the instruction that calls the subroutine, just to make it easier to debug what goes wrong. Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: gdb command "next" wrongly working as command "step" 2019-08-26 13:18 ` Pedro Alves @ 2019-09-01 19:06 ` William Tambe 2019-09-05 11:59 ` Andrew Burgess 0 siblings, 1 reply; 11+ messages in thread From: William Tambe @ 2019-09-01 19:06 UTC (permalink / raw) To: Pedro Alves; +Cc: Jan Kratochvil, gdb On Mon, Aug 26, 2019 at 8:18 AM Pedro Alves <palves@redhat.com> wrote: > > On 8/25/19 8:04 PM, William Tambe wrote: > > Please see below, less noisy GDB output showing a working backtrace > > where I can see the caller in frame #1; but yet GDB command "next" is > > working as though it was "step"; any suggestion where else I could > > look ? > > - You'll just have to debug gdb. Try to figure out why this code, inside > the "infrun: stepped into subroutine" block,seemingly isn't being reached: > > /* Set a breakpoint at callee's return address (the address > at which the caller will resume). */ > insert_step_resume_breakpoint_at_caller (frame); > > - I'd use "nexti" instead of "next" to try stepping over the > instruction that calls the subroutine, just to make it easier > to debug what goes wrong. I have debugged the issue that I am having to be originating from frame_id_eq(); see below patch that I apply to work-around the issue I am having; I am sure it is not the fix. frame_id_eq() is used to check whether two frames are identical, and in comparing the two frames it will compare whether the two frames have the same program-counter value. I caught GDB comparing two identical frames differing only by their program-counter values; where in one frame, the program-counter value would be at the first instruction of the line making the function-call, while in the other frame the program-counter value would be at the return-address from the function-call. I will guess that, when "next" is used, GDB does not always use the frame program-counter value after the jump-and-link instruction within the line making the function-call, but instead use the frame program-counter value of the first instruction of the line making function-call. To get the program-counter value of a frame, I see GDB calling the callback function (struct frame_unwind *)->prev_register(); and in my GDB port, that function returns the program-counter value after the jump-and-link instruction; I will guess that GDB does not always use that callback function to get the program-counter value of a frame; in that case, what would be the other function that GDB uses to get the program-counter value of a frame ? As mentioned above, here-after is patch that I apply to work-around the issue I am having. Any idea what I am missing in my GDB port such that I wouldn't need the patch below ? diff --git a/gdb/frame.c b/gdb/frame.c index d8b5f819f1..c75f8ead38 100644 --- a/gdb/frame.c +++ b/gdb/frame.c @@ -707,10 +707,14 @@ frame_id_eq (struct frame_id l, struct frame_id r) else if (l.stack_status != r.stack_status || l.stack_addr != r.stack_addr) /* If .stack addresses are different, the frames are different. */ eq = 0; +#if 0 + // ### Disabled for now; as .code addresses could be + // ### different while still being for the same frame. else if (l.code_addr_p && r.code_addr_p && l.code_addr != r.code_addr) /* An invalid code addr is a wild card. If .code addresses are different, the frames are different. */ eq = 0; +#endif else if (l.special_addr_p && r.special_addr_p && l.special_addr != r.special_addr) /* An invalid special addr is a wild card (or unused). Otherwise > > Thanks, > Pedro Alves ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: gdb command "next" wrongly working as command "step" 2019-09-01 19:06 ` William Tambe @ 2019-09-05 11:59 ` Andrew Burgess 0 siblings, 0 replies; 11+ messages in thread From: Andrew Burgess @ 2019-09-05 11:59 UTC (permalink / raw) To: William Tambe; +Cc: Pedro Alves, Jan Kratochvil, gdb * William Tambe <tambewilliam@gmail.com> [2019-09-01 14:05:56 -0500]: > On Mon, Aug 26, 2019 at 8:18 AM Pedro Alves <palves@redhat.com> wrote: > > > > On 8/25/19 8:04 PM, William Tambe wrote: > > > Please see below, less noisy GDB output showing a working backtrace > > > where I can see the caller in frame #1; but yet GDB command "next" is > > > working as though it was "step"; any suggestion where else I could > > > look ? > > > > - You'll just have to debug gdb. Try to figure out why this code, inside > > the "infrun: stepped into subroutine" block,seemingly isn't being reached: > > > > /* Set a breakpoint at callee's return address (the address > > at which the caller will resume). */ > > insert_step_resume_breakpoint_at_caller (frame); > > > > - I'd use "nexti" instead of "next" to try stepping over the > > instruction that calls the subroutine, just to make it easier > > to debug what goes wrong. > > I have debugged the issue that I am having to be originating from > frame_id_eq(); see below patch that I apply to work-around the issue I > am having; I am sure it is not the fix. > > frame_id_eq() is used to check whether two frames are identical, and > in comparing the two frames it will compare whether the two frames > have the same program-counter value. > > I caught GDB comparing two identical frames differing only by their > program-counter values; where in one frame, the program-counter value > would be at the first instruction of the line making the > function-call, while in the other frame the program-counter value > would be at the return-address from the function-call. From this description, my guess is that your bug is in your implementation of the frame_this_id method. The frame_id of a function is (basically) made of a $sp and $pc value. The $sp should be the $sp on entry to the frame (or the frame base address, which is similar), and the $pc should be for the start of the function. It sounds to me (just a guess based on the above) that your frame_this_id method is just using the current $pc in the frame to build the frame id. This would explain the issues you are seeing. Thanks, Andrew > > I will guess that, when "next" is used, GDB does not always use the > frame program-counter value after the jump-and-link instruction within > the line making the function-call, but instead use the frame > program-counter value of the first instruction of the line making > function-call. > To get the program-counter value of a frame, I see GDB calling the > callback function (struct frame_unwind *)->prev_register(); and in my > GDB port, that function returns the program-counter value after the > jump-and-link instruction; I will guess that GDB does not always use > that callback function to get the program-counter value of a frame; in > that case, what would be the other function that GDB uses to get the > program-counter value of a frame ? > > As mentioned above, here-after is patch that I apply to work-around > the issue I am having. > Any idea what I am missing in my GDB port such that I wouldn't need > the patch below ? > > diff --git a/gdb/frame.c b/gdb/frame.c > index d8b5f819f1..c75f8ead38 100644 > --- a/gdb/frame.c > +++ b/gdb/frame.c > @@ -707,10 +707,14 @@ frame_id_eq (struct frame_id l, struct frame_id r) > else if (l.stack_status != r.stack_status || l.stack_addr != r.stack_addr) > /* If .stack addresses are different, the frames are different. */ > eq = 0; > +#if 0 > + // ### Disabled for now; as .code addresses could be > + // ### different while still being for the same frame. > else if (l.code_addr_p && r.code_addr_p && l.code_addr != r.code_addr) > /* An invalid code addr is a wild card. If .code addresses are > different, the frames are different. */ > eq = 0; > +#endif > else if (l.special_addr_p && r.special_addr_p > && l.special_addr != r.special_addr) > /* An invalid special addr is a wild card (or unused). Otherwise > > > > > > Thanks, > > Pedro Alves ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2019-09-05 11:59 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-08-18 3:36 gdb command "next" wrongly working as command "step" William Tambe 2019-08-18 4:16 ` Jan Kratochvil 2019-08-18 8:32 ` William Tambe 2019-08-18 9:06 ` Jan Kratochvil 2019-08-23 21:33 ` William Tambe 2019-08-23 21:54 ` Pedro Alves 2019-08-24 3:36 ` William Tambe 2019-08-25 19:04 ` William Tambe 2019-08-26 13:18 ` Pedro Alves 2019-09-01 19:06 ` William Tambe 2019-09-05 11:59 ` Andrew Burgess
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).