* [PATCH 0/2] Fix reverse stepping multiple contiguous PC ranges over the line table.
@ 2023-08-07 18:54 Carl Love
2023-08-07 19:03 ` [PATCH 1/2 ver 2] " Carl Love
2023-08-07 19:03 ` [PATCH 2/2 ver 7] " Carl Love
0 siblings, 2 replies; 13+ messages in thread
From: Carl Love @ 2023-08-07 18:54 UTC (permalink / raw)
To: Simon Marchi, Bruno Larsen, gdb-patches, UlrichWeigand, pedro
Cc: luis.machado, cel
GDB maintainers:
Per recent discussions with Bruno on how gdb should behave when reverse
stepping from a function call to the previous line:
https://sourceware.org/pipermail/gdb-patches/2023-July/201035.html
I have updated the second patch in the series to address his comments.
The current behavior of gdb when executing in reverse is gdb stops at
the call to a function, then a reverse-step or reverse-next stops at
the beginning of the same line instead of the previous line. Bruno
pointed out that gdb on clang stops at the previous line not at the
beginning of the line.
The first patch in the series has not been changed. I am reposting it
along with the second patch so it doesn't get lost.
The patch series has been tested on Power10 LE and on X86-64.
Carl
^ permalink raw reply [flat|nested] 13+ messages in thread* [PATCH 1/2 ver 2] Fix reverse stepping multiple contiguous PC ranges over the line table. 2023-08-07 18:54 [PATCH 0/2] Fix reverse stepping multiple contiguous PC ranges over the line table Carl Love @ 2023-08-07 19:03 ` Carl Love 2023-08-08 10:04 ` Guinevere Larsen 2023-08-07 19:03 ` [PATCH 2/2 ver 7] " Carl Love 1 sibling, 1 reply; 13+ messages in thread From: Carl Love @ 2023-08-07 19:03 UTC (permalink / raw) To: Simon Marchi, Bruno Larsen, gdb-patches, UlrichWeigand, pedro Cc: luis.machado, cel Simon, GDB maintainers: Version 2, updated the compiler check and handling for gcc version 6 and earlier. Retested on Power 10. Per the comments on version 4 for the gdb.reverse/func-map-to-same- line.exp, I have added support to proc gdb_compile to enable or disable generating line information as part of the debug information. The two new options are column-info and no-column-info. This patch implements the new options for gdb_compile. These options have been tested with patch 2 of 2 on PowerPC with the GCC and clang compilers. Please let me know if the patch is acceptable for mainline. Thanks. Carl -------------------------- Add gdb_compile options column-info and no-column-info This patch adds two new options to gdb_compile to specify if the compile should or should not generate the line table information. The options are supported on clang and gcc version 7 and newer. Patch has been tested on PowerPC with both gcc and clang. --- gdb/testsuite/lib/gdb.exp | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index 36bf738c667..bffbbf38b09 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -4896,6 +4896,8 @@ proc quote_for_host { args } { # debug information # - text_segment=addr: Tell the linker to place the text segment at ADDR. # - build-id: Ensure the final binary includes a build-id. +# - no-column-info: Disable generation of column table information. +# - column-info: Enable generation of column table information. # # And here are some of the not too obscure options understood by DejaGnu that # influence the compilation: @@ -5105,6 +5107,38 @@ proc gdb_compile {source dest type options} { } else { error "Don't know how to handle text_segment option." } + } elseif { $opt == "column-info" } { + # If GCC or clang does not support column-info, compilation + # will fail and the usupported column-info option will be + # reported as such. + if {[test_compiler_info {gcc-*}]} { + lappend new_options "additional_flags=-gcolumn-info" + + } elseif {[test_compiler_info {clang-*}]} { + lappend new_options "additional_flags=-gcolumn-info" + + } else { + error "Don't know how to handle gcolumn-info option." + } + + } elseif { $opt == "no-column-info" } { + if {[test_compiler_info {gcc-*}]} { + if {[test_compiler_info {gcc-[1-6]-*}]} { + # In this case, don't add the compile line option and + # the result will be the same as using no-column-info + # on a version that supports the option. + warning "gdb_compile option no-column-info not supported, ignoring." + } else { + lappend new_options "additional_flags=-gno-column-info" + } + + } elseif {[test_compiler_info {clang-*}]} { + lappend new_options "additional_flags=-gno-column-info" + + } else { + error "Don't know how to handle gno-column-info option." + } + } else { lappend new_options $opt } -- 2.37.2 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2 ver 2] Fix reverse stepping multiple contiguous PC ranges over the line table. 2023-08-07 19:03 ` [PATCH 1/2 ver 2] " Carl Love @ 2023-08-08 10:04 ` Guinevere Larsen 2023-08-08 15:38 ` Carl Love 0 siblings, 1 reply; 13+ messages in thread From: Guinevere Larsen @ 2023-08-08 10:04 UTC (permalink / raw) To: Carl Love, Simon Marchi, gdb-patches, UlrichWeigand, pedro; +Cc: luis.machado On 07/08/2023 21:03, Carl Love wrote: > Simon, GDB maintainers: > > Version 2, updated the compiler check and handling for gcc version 6 > and earlier. Retested on Power 10. > > Per the comments on version 4 for the gdb.reverse/func-map-to-same- > line.exp, I have added support to proc gdb_compile to enable or disable > generating line information as part of the debug information. The two > new options are column-info and no-column-info. > > This patch implements the new options for gdb_compile. > > These options have been tested with patch 2 of 2 on PowerPC with the > GCC and clang compilers. > > Please let me know if the patch is acceptable for mainline. Thanks. > > Carl > > > -------------------------- > Add gdb_compile options column-info and no-column-info > > This patch adds two new options to gdb_compile to specify if the compile > should or should not generate the line table information. The > options are supported on clang and gcc version 7 and newer. > > Patch has been tested on PowerPC with both gcc and clang. > --- > gdb/testsuite/lib/gdb.exp | 34 ++++++++++++++++++++++++++++++++++ > 1 file changed, 34 insertions(+) > > diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp > index 36bf738c667..bffbbf38b09 100644 > --- a/gdb/testsuite/lib/gdb.exp > +++ b/gdb/testsuite/lib/gdb.exp > @@ -4896,6 +4896,8 @@ proc quote_for_host { args } { > # debug information > # - text_segment=addr: Tell the linker to place the text segment at ADDR. > # - build-id: Ensure the final binary includes a build-id. > +# - no-column-info: Disable generation of column table information. > +# - column-info: Enable generation of column table information. > # > # And here are some of the not too obscure options understood by DejaGnu that > # influence the compilation: > @@ -5105,6 +5107,38 @@ proc gdb_compile {source dest type options} { > } else { > error "Don't know how to handle text_segment option." > } > + } elseif { $opt == "column-info" } { > + # If GCC or clang does not support column-info, compilation > + # will fail and the usupported column-info option will be > + # reported as such. > + if {[test_compiler_info {gcc-*}]} { I think you missed a bit on an old comment from simon. Way back in may, in this email https://sourceware.org/pipermail/gdb-patches/2023-May/199523.html, he mentioned: For instance, if you used no-column-info with gcc 6 (which doesn't support column info at all), gdb_compile should succeed, even if there isn't an option to disable column info with that compiler. If you used column-info with gcc 6, gdb_compile would fail. So I think this bit should throw an error if it detects gcc-[1-6]. > + lappend new_options "additional_flags=-gcolumn-info" > + > + } elseif {[test_compiler_info {clang-*}]} { I did some digging, and column-info were added in llvm back in october 2012 (commit a2f7eb7c52cdc), which seems to mean support was added in llvm 3.2, but I don't see any mention in the release notes. In my opinion, this is old enough that we don't need to have a special case, but I wanted to mention, in case some maintainer thinks it should be dealt with. If we should, before then, it seems that clang WOULD add column info by default, so it should compile with a warning here, and fail if the user requested no column info -- Cheers, Guinevere Larsen She/Her/Hers > + lappend new_options "additional_flags=-gcolumn-info" > + > + } else { > + error "Don't know how to handle gcolumn-info option." > + } > + > + } elseif { $opt == "no-column-info" } { > + if {[test_compiler_info {gcc-*}]} { > + if {[test_compiler_info {gcc-[1-6]-*}]} { > + # In this case, don't add the compile line option and > + # the result will be the same as using no-column-info > + # on a version that supports the option. > + warning "gdb_compile option no-column-info not supported, ignoring." > + } else { > + lappend new_options "additional_flags=-gno-column-info" > + } > + > + } elseif {[test_compiler_info {clang-*}]} { > + lappend new_options "additional_flags=-gno-column-info" > + > + } else { > + error "Don't know how to handle gno-column-info option." > + } > + > } else { > lappend new_options $opt > } ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [PATCH 1/2 ver 2] Fix reverse stepping multiple contiguous PC ranges over the line table. 2023-08-08 10:04 ` Guinevere Larsen @ 2023-08-08 15:38 ` Carl Love 2023-08-08 15:45 ` Guinevere Larsen 0 siblings, 1 reply; 13+ messages in thread From: Carl Love @ 2023-08-08 15:38 UTC (permalink / raw) To: Guinevere Larsen, Simon Marchi, gdb-patches, UlrichWeigand, pedro Cc: luis.machado, cel Guinevere: On Tue, 2023-08-08 at 12:04 +0200, Guinevere Larsen wrote: > > <snip> > On 07/08/2023 21:03, Carl Love wrote: > > > > diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp > > index 36bf738c667..bffbbf38b09 100644 > > --- a/gdb/testsuite/lib/gdb.exp > > +++ b/gdb/testsuite/lib/gdb.exp > > @@ -4896,6 +4896,8 @@ proc quote_for_host { args } { > > # debug information > > # - text_segment=addr: Tell the linker to place the text > > segment at ADDR. > > # - build-id: Ensure the final binary includes a build-id. > > +# - no-column-info: Disable generation of column table > > information. > > +# - column-info: Enable generation of column table information. > > # > > # And here are some of the not too obscure options understood by > > DejaGnu that > > # influence the compilation: > > @@ -5105,6 +5107,38 @@ proc gdb_compile {source dest type options} > > { > > } else { > > error "Don't know how to handle text_segment > > option." > > } > > + } elseif { $opt == "column-info" } { > > + # If GCC or clang does not support column-info, compilation > > + # will fail and the usupported column-info option will be > > + # reported as such. > > + if {[test_compiler_info {gcc-*}]} { > > I think you missed a bit on an old comment from simon. Way back in > may, > in this email > https://sourceware.org/pipermail/gdb-patches/2023-May/199523.html , > he > mentioned: > > For instance, if you used no-column-info with gcc 6 > (which doesn't support column info at all), gdb_compile should > succeed, > even if there isn't an option to disable column info with that > compiler. > If you used column-info with gcc 6, gdb_compile would fail. > > So I think this bit should throw an error if it detects gcc-[1-6]. It has been awhile, but as I recall, we decided that the we would specify column-info and if the compiler doesn't support it then the compiler will complain (i.e. fail) and we will let the failure be handled by the normal compiler failure path. I think that will work fine? If there is some concern that is not sufficient, I would be happy to put in the test if {[test_compiler_info {gcc-[1-6]-*}]} for the $opt == "column-info" to have the script flag the error. Thoughts? In the case where the compiler doesn't handle the no-column-info flag, i.e. gcc 1-6, we handle that case by not adding the flag so the compiler will not flag the error and fail. In that case, it isn't going to generate the column info anyways so we don't need to specify no-column info. > > > + lappend new_options "additional_flags=-gcolumn-info" > > + > > + } elseif {[test_compiler_info {clang-*}]} { > > I did some digging, and column-info were added in llvm back in > october > 2012 (commit a2f7eb7c52cdc), which seems to mean support was added > in > llvm 3.2, but I don't see any mention in the release notes. In my > opinion, this is old enough that we don't need to have a special > case, > but I wanted to mention, in case some maintainer thinks it should be > dealt with. > > If we should, before then, it seems that clang WOULD add column info > by > default, so it should compile with a warning here, and fail if the > user > requested no column info > Carl ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2 ver 2] Fix reverse stepping multiple contiguous PC ranges over the line table. 2023-08-08 15:38 ` Carl Love @ 2023-08-08 15:45 ` Guinevere Larsen 0 siblings, 0 replies; 13+ messages in thread From: Guinevere Larsen @ 2023-08-08 15:45 UTC (permalink / raw) To: Carl Love, Simon Marchi, gdb-patches, UlrichWeigand, pedro; +Cc: luis.machado On 08/08/2023 17:38, Carl Love wrote: > Guinevere: > > On Tue, 2023-08-08 at 12:04 +0200, Guinevere Larsen wrote: > <snip> > >> On 07/08/2023 21:03, Carl Love wrote: >>> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp >>> index 36bf738c667..bffbbf38b09 100644 >>> --- a/gdb/testsuite/lib/gdb.exp >>> +++ b/gdb/testsuite/lib/gdb.exp >>> @@ -4896,6 +4896,8 @@ proc quote_for_host { args } { >>> # debug information >>> # - text_segment=addr: Tell the linker to place the text >>> segment at ADDR. >>> # - build-id: Ensure the final binary includes a build-id. >>> +# - no-column-info: Disable generation of column table >>> information. >>> +# - column-info: Enable generation of column table information. >>> # >>> # And here are some of the not too obscure options understood by >>> DejaGnu that >>> # influence the compilation: >>> @@ -5105,6 +5107,38 @@ proc gdb_compile {source dest type options} >>> { >>> } else { >>> error "Don't know how to handle text_segment >>> option." >>> } >>> + } elseif { $opt == "column-info" } { >>> + # If GCC or clang does not support column-info, compilation >>> + # will fail and the usupported column-info option will be >>> + # reported as such. >>> + if {[test_compiler_info {gcc-*}]} { >> I think you missed a bit on an old comment from simon. Way back in >> may, >> in this email >> https://sourceware.org/pipermail/gdb-patches/2023-May/199523.html , >> he >> mentioned: >> >> For instance, if you used no-column-info with gcc 6 >> (which doesn't support column info at all), gdb_compile should >> succeed, >> even if there isn't an option to disable column info with that >> compiler. >> If you used column-info with gcc 6, gdb_compile would fail. >> >> So I think this bit should throw an error if it detects gcc-[1-6]. > It has been awhile, but as I recall, we decided that the we would > specify column-info and if the compiler doesn't support it then the > compiler will complain (i.e. fail) and we will let the failure be > handled by the normal compiler failure path. I think that will work > fine? If there is some concern that is not sufficient, I would be > happy to put in the test if {[test_compiler_info {gcc-[1-6]-*}]} for > the $opt == "column-info" to have the script flag the error. > Thoughts? oh, I see. I must have misread when looking back at that conversation. Sorry for the noise. Also, disregard my comments about LLVM. I checked on IRC and the oldest GCC we support compiling/using for usptream stuff is form 2014, so I think we dont have to worry about 2012 clang :) All in all, this patch looks good to go in. Reviewed-By: Guinevere Larsen <blarsen@redhat.com> I hope the maintainers approve this series soon, it is a long time coming! -- Cheers, Guinevere Larsen She/Her/Hers > > In the case where the compiler doesn't handle the no-column-info flag, > i.e. gcc 1-6, we handle that case by not adding the flag so the > compiler will not flag the error and fail. In that case, it isn't > going to generate the column info anyways so we don't need to specify > no-column info. > > >>> + lappend new_options "additional_flags=-gcolumn-info" >>> + >>> + } elseif {[test_compiler_info {clang-*}]} { >> I did some digging, and column-info were added in llvm back in >> october >> 2012 (commit a2f7eb7c52cdc), which seems to mean support was added >> in >> llvm 3.2, but I don't see any mention in the release notes. In my >> opinion, this is old enough that we don't need to have a special >> case, >> but I wanted to mention, in case some maintainer thinks it should be >> dealt with. >> >> If we should, before then, it seems that clang WOULD add column info >> by >> default, so it should compile with a warning here, and fail if the >> user >> requested no column info >> > Carl > ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 2/2 ver 7] Fix reverse stepping multiple contiguous PC ranges over the line table. 2023-08-07 18:54 [PATCH 0/2] Fix reverse stepping multiple contiguous PC ranges over the line table Carl Love 2023-08-07 19:03 ` [PATCH 1/2 ver 2] " Carl Love @ 2023-08-07 19:03 ` Carl Love 2023-08-08 14:14 ` Guinevere Larsen 1 sibling, 1 reply; 13+ messages in thread From: Carl Love @ 2023-08-07 19:03 UTC (permalink / raw) To: Simon Marchi, Bruno Larsen, gdb-patches, UlrichWeigand, pedro Cc: luis.machado, cel Bruno, Simon, GDB maintainers: Version 7, addressed behavior of GDB when stepping backward thru a function call as mentioned by Bruno. GDB would stop at the function call and then a reverse step/next would cause GDB to stop at the first instruction of the same line as the function call instead of stopping in the previous line. The behavior was fixed and the various test programs were updated to remove one of the two reverse step or next instructions required to reach the previous line. Version 6, fixed various code style issues in the GDB source. The testcases were updated to use with_test_prefix for each gdb test in the step and next test cases, switch using the standard_testfile, use foreach_with_prefix to combine otherwise identical tests. Retested on Power 10. Version 5, changed comments in test case func-map-to-same-line.c. Patch 1/2 implemented the new options for gdb_compile. Updated the call to proc run_tests to use the new gdb_compile options in a foreach_with_prefix loop. Version 4, additional fixes for gcc version check, wrap function calls using "with_test_prefix", move load_lib dwarf.exe. Fixed typo noted by Luis. Version 3, added the gcc version check as discussed further from version 2 of the patch. Also updated the tests to check for supporting reverse execution rather than requiring recording. I also noticed there were a couple more instances of a requirement check, i.e. if [] which I changed to "require" per the current style for checking on the test requirements. The following patch fixes issues on PowerPC with the reverse-step and reverse-next instructions when there are multiple assignment statements on the same line and when there are multiple function calls on the same line. The commit log below discusses these issues in further depth. The discussion included what the correct operation should be for these commands based on the GDB documentation. The proposed patch at that time changed how the commands worked on other platforms such as X86 in a way they no longer matched the documentation. The issue is the line table contains multiple entries for the same source line. The patch adds a function to search the line table to find the address of the first instruction of a line. When setup up the reverse stepping range, the function is called to make sure the start of the range corresponds to the address of the first instruction for the line. This approach was used. When Luis initially developed the patch, he considered merging the contiguous ranges in the line table when reading the line tables. He decided it was better to work with the data directly in the line table rather than creating and using a modified version of the line table. The following patch fixes the execution of the reveres-step and reverse-next commands for both senarios of multiple statements on the same line for PowerPC and aarch64-linux. Unlike the previous patch, it does not change the operation of the commands on other platforms, i.e. X86. The patch adds new test cases for both scenarios to verify they work correctly. The patch has been tested on PowerPC, Intel X86 and aarch64-linux with no new regression failures. Please let me know if the patch is acceptable for mainline. Thanks. Carl -------------------------------- Fix reverse stepping multiple contiguous PC ranges over the line table. There are a couple of scenarios where the GDB reverse-step and reverse-next commands do not work correctly. Scenario 1 issue description by Luis Machado: When running GDB's testsuite on aarch64-linux/Ubuntu 20.04 (also spotted on the ppc backend), I noticed some failures in gdb.reverse/solib-precsave.exp and gdb.reverse/solib-reverse.exp. The failure happens around the following code: 38 b[1] = shr2(17); /* middle part two */ 40 b[0] = 6; b[1] = 9; /* generic statement, end part two */ 42 shr1 ("message 1\n"); /* shr1 one */ Normal execution: - step from line 38 will land on line 40. - step from line 40 will land on line 42. Reverse execution: - step from line 42 will land on line 40. - step from line 40 will land on line 40. - step from line 40 will land on line 38. V The problem here is that line 40 contains two contiguous but distinct PC ranges in the line table, like so: Line 40 - [0x7ec ~ 0x7f4] Line 40 - [0x7f4 ~ 0x7fc] The two distinct ranges are generated because GCC started outputting source column information, which GDB doesn't take into account at the moment. When stepping forward from line 40, we skip both of these ranges and land on line 42. When stepping backward from line 42, we stop at the start PC of the second (or first, going backwards) range of line 40. Since we've reached ecs->event_thread->control.step_range_start, we stop stepping backwards. --------------------------------------------------------- Scenario 2 issue described by Pedro Alves: The following explanation of the issue was taken from the gdb mailing list discussion of the withdrawn patch to change the behavior of the reverse-step and reverse-next commands. Specifically, message from Pedro Alves <pedro@palves.net> where he demonstrates the issue where you have multiple function calls on the same source code line: https://sourceware.org/pipermail/gdb-patches/2023-January/196110.html The source line looks like: func1 (); func2 (); so stepping backwards over that line should always stop at the first instruction of the line, not in the middle. Let's simplify this. Here's the full source code of my example: (gdb) list 1 1 void func1 () 2 { 3 } 4 5 void func2 () 6 { 7 } 8 9 int main () 10 { 11 func1 (); func2 (); 12 } Compiled with: $ gcc reverse.c -o reverse -g3 -O0 $ gcc -v ... gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04) Now let's debug it with target record, using current gdb git master (f3d8ae90b236), without your patch: $ gdb ~/reverse GNU gdb (GDB) 14.0.50.20230124-git ... Reading symbols from /home/pedro/reverse... (gdb) start Temporary breakpoint 1 at 0x1147: file reverse.c, line 11. Starting program: /home/pedro/reverse [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Temporary breakpoint 1, main () at reverse.c:11 11 func1 (); func2 (); (gdb) record (gdb) disassemble /s Dump of assembler code for function main: reverse.c: 10 { 0x000055555555513f <+0>: endbr64 0x0000555555555143 <+4>: push %rbp 0x0000555555555144 <+5>: mov %rsp,%rbp 11 func1 (); func2 (); => 0x0000555555555147 <+8>: mov $0x0,%eax 0x000055555555514c <+13>: call 0x555555555129 <func1> 0x0000555555555151 <+18>: mov $0x0,%eax 0x0000555555555156 <+23>: call 0x555555555134 <func2> 0x000055555555515b <+28>: mov $0x0,%eax 12 } 0x0000555555555160 <+33>: pop %rbp 0x0000555555555161 <+34>: ret End of assembler dump. (gdb) n 12 } So far so good, a "next" stepped over the whole of line 11 and stopped at line 12. Let's confirm where we are now: (gdb) disassemble /s Dump of assembler code for function main: reverse.c: 10 { 0x000055555555513f <+0>: endbr64 0x0000555555555143 <+4>: push %rbp 0x0000555555555144 <+5>: mov %rsp,%rbp 11 func1 (); func2 (); 0x0000555555555147 <+8>: mov $0x0,%eax 0x000055555555514c <+13>: call 0x555555555129 <func1> 0x0000555555555151 <+18>: mov $0x0,%eax 0x0000555555555156 <+23>: call 0x555555555134 <func2> 0x000055555555515b <+28>: mov $0x0,%eax 12 } => 0x0000555555555160 <+33>: pop %rbp 0x0000555555555161 <+34>: ret End of assembler dump. Good, we're at the first instruction of line 12. Now let's undo the "next", with "reverse-next": (gdb) reverse-next 11 func1 (); func2 (); Seemingly stopped at line 11. Let's see exactly where: (gdb) disassemble /s Dump of assembler code for function main: reverse.c: 10 { 0x000055555555513f <+0>: endbr64 0x0000555555555143 <+4>: push %rbp 0x0000555555555144 <+5>: mov %rsp,%rbp 11 func1 (); func2 (); 0x0000555555555147 <+8>: mov $0x0,%eax 0x000055555555514c <+13>: call 0x555555555129 <func1> => 0x0000555555555151 <+18>: mov $0x0,%eax 0x0000555555555156 <+23>: call 0x555555555134 <func2> 0x000055555555515b <+28>: mov $0x0,%eax 12 } 0x0000555555555160 <+33>: pop %rbp 0x0000555555555161 <+34>: ret End of assembler dump. (gdb) And lo, we stopped in the middle of line 11! That is a bug, we should have stepped back all the way to the beginning of the line. The "reverse-next" should have fully undone the prior "next" command. The above issues were fixed by introducing a new function that looks for adjacent PC ranges for the same line, until we notice a line change. Then we take that as the start PC of the range. The new start PC for the range is used for the control.step_range_start when setting up a step range. The test case gdb.reverse/map-to-same-line.exp is added to test the fix for the issues in scenario 1. The test case gdb.reverse/func-map-to-same-line.exp was added to test the fix for scenario 2 when the binary was compiled with and without line table information. bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28426 Co-authored-by: Luis Machado <luis.machado@arm.com> Co-authored-by: Carl Love <cel@us.ibm.com> --- gdb/infcmd.c | 13 ++ gdb/infrun.c | 59 +++++++ gdb/symtab.c | 49 ++++++ gdb/symtab.h | 16 ++ gdb/testsuite/gdb.mi/mi-reverse.exp | 5 +- .../gdb.reverse/finish-reverse-next.exp | 42 ++--- .../gdb.reverse/func-map-to-same-line.c | 37 +++++ .../gdb.reverse/func-map-to-same-line.exp | 139 ++++++++++++++++ gdb/testsuite/gdb.reverse/map-to-same-line.c | 58 +++++++ .../gdb.reverse/map-to-same-line.exp | 153 ++++++++++++++++++ 10 files changed, 537 insertions(+), 34 deletions(-) create mode 100644 gdb/testsuite/gdb.reverse/func-map-to-same-line.c create mode 100644 gdb/testsuite/gdb.reverse/func-map-to-same-line.exp create mode 100644 gdb/testsuite/gdb.reverse/map-to-same-line.c create mode 100644 gdb/testsuite/gdb.reverse/map-to-same-line.exp diff --git a/gdb/infcmd.c b/gdb/infcmd.c index 15702f84894..add0eadd8c1 100644 --- a/gdb/infcmd.c +++ b/gdb/infcmd.c @@ -982,6 +982,19 @@ prepare_one_step (thread_info *tp, struct step_command_fsm *sm) &tp->control.step_range_start, &tp->control.step_range_end); + if (execution_direction == EXEC_REVERSE) + { + symtab_and_line sal = find_pc_line (pc, 0); + symtab_and_line sal_start + = find_pc_line (tp->control.step_range_start, 0); + + if (sal.line == sal_start.line) + /* Executing in reverse, the step_range_start address is in + the same line. We want to stop in the previous line so + move step_range_start before the current line. */ + tp->control.step_range_start--; + } + /* There's a problem in gcc (PR gcc/98780) that causes missing line table entries, which results in a too large stepping range. Use inlined_subroutine info to make the range more narrow. */ diff --git a/gdb/infrun.c b/gdb/infrun.c index 8286026e6c6..32ba852f227 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -115,6 +115,9 @@ static struct async_event_handler *infrun_async_inferior_event_token; Starts off as -1, indicating "never enabled/disabled". */ static int infrun_is_async = -1; +static CORE_ADDR update_line_range_start (CORE_ADDR pc, + struct execution_control_state *ecs); + /* See infrun.h. */ void @@ -6884,6 +6887,27 @@ handle_signal_stop (struct execution_control_state *ecs) process_event_stop_test (ecs); } +/* Return the address for the beginning of the line. */ + +CORE_ADDR +update_line_range_start (CORE_ADDR pc, struct execution_control_state *ecs) +{ + /* The line table may have multiple entries for the same source code line. + Given the PC, check the line table and return the PC that corresponds + to the line table entry for the source line that PC is in. */ + CORE_ADDR start_line_pc = ecs->event_thread->control.step_range_start; + gdb::optional<CORE_ADDR> real_range_start; + + /* Call find_line_range_start to get the smallest address in the + linetable for multiple Line X entries in the line table. */ + real_range_start = find_line_range_start (pc); + + if (real_range_start.has_value ()) + start_line_pc = *real_range_start; + + return start_line_pc; +} + /* Come here when we've got some debug event / signal we can explain (IOW, not a random signal), and test whether it should cause a stop, or whether we should resume the inferior (transparently). @@ -7685,6 +7709,28 @@ process_event_stop_test (struct execution_control_state *ecs) if (stop_pc_sal.is_stmt) { + if (execution_direction == EXEC_REVERSE) + { + /* We are stepping backwards make sure we have reached the + beginning of the line. */ + CORE_ADDR stop_pc = ecs->event_thread->stop_pc (); + CORE_ADDR start_line_pc + = update_line_range_start (stop_pc, ecs); + + if (stop_pc != start_line_pc) + { + /* Have not reached the beginning of the source code line. + Set a step range. Execution should stop in any function + calls we execute back into before reaching the beginning + of the line. */ + ecs->event_thread->control.step_range_start = start_line_pc; + ecs->event_thread->control.step_range_end = stop_pc; + set_step_info (ecs->event_thread, frame, stop_pc_sal); + keep_going (ecs); + return; + } + } + /* We are at the start of a statement. So stop. Note that we don't stop if we step into the middle of a @@ -7747,6 +7793,19 @@ process_event_stop_test (struct execution_control_state *ecs) set_step_info (ecs->event_thread, frame, stop_pc_sal); infrun_debug_printf ("keep going"); + + if (execution_direction == EXEC_REVERSE) + { + CORE_ADDR stop_pc = ecs->event_thread->stop_pc (); + + /* Make sure the stop_pc is set to the beginning of the line. */ + if (stop_pc != ecs->event_thread->control.step_range_start) + { + stop_pc = update_line_range_start (stop_pc, ecs); + ecs->event_thread->control.step_range_start = stop_pc; + } + } + keep_going (ecs); } diff --git a/gdb/symtab.c b/gdb/symtab.c index 0117a2a59d7..c38bb01b747 100644 --- a/gdb/symtab.c +++ b/gdb/symtab.c @@ -3284,6 +3284,55 @@ find_pc_line (CORE_ADDR pc, int notcurrent) return sal; } +/* Compare two symtab_and_line entries. Return true if both have + the same line number and the same symtab pointer. That means we + are dealing with two entries from the same line and from the same + source file. + + Return false otherwise. */ + +static bool +sal_line_symtab_matches_p (const symtab_and_line &sal1, + const symtab_and_line &sal2) +{ + return sal1.line == sal2.line && sal1.symtab == sal2.symtab; +} + +/* See symtah.h. */ + +gdb::optional<CORE_ADDR> +find_line_range_start (CORE_ADDR pc) +{ + struct symtab_and_line current_sal = find_pc_line (pc, 0); + + if (current_sal.line == 0) + return {}; + + struct symtab_and_line prev_sal = find_pc_line (current_sal.pc - 1, 0); + + /* If the previous entry is for a different line, that means we are already + at the entry with the start PC for this line. */ + if (!sal_line_symtab_matches_p (prev_sal, current_sal)) + return current_sal.pc; + + /* Otherwise, keep looking for entries for the same line but with + smaller PC's. */ + bool done = false; + CORE_ADDR prev_pc; + while (!done) + { + prev_pc = prev_sal.pc; + + prev_sal = find_pc_line (prev_pc - 1, 0); + + /* Did we notice a line change? If so, we are done with the search. */ + if (!sal_line_symtab_matches_p (prev_sal, current_sal)) + done = true; + } + + return prev_pc; +} + /* See symtab.h. */ struct symtab * diff --git a/gdb/symtab.h b/gdb/symtab.h index ee4729b14cd..82bc013622f 100644 --- a/gdb/symtab.h +++ b/gdb/symtab.h @@ -2354,6 +2354,22 @@ extern struct symtab_and_line find_pc_line (CORE_ADDR, int); extern struct symtab_and_line find_pc_sect_line (CORE_ADDR, struct obj_section *, int); +/* Given PC, and assuming it is part of a range of addresses that is part of a + line, go back through the linetable and find the starting PC of that + line. + + For example, suppose we have 3 PC ranges for line X: + + Line X - [0x0 - 0x8] + Line X - [0x8 - 0x10] + Line X - [0x10 - 0x18] + + If we call the function with PC == 0x14, we want to return 0x0, as that is + the starting PC of line X, and the ranges are contiguous. +*/ + +extern gdb::optional<CORE_ADDR> find_line_range_start (CORE_ADDR pc); + /* Wrapper around find_pc_line to just return the symtab. */ extern struct symtab *find_pc_line_symtab (CORE_ADDR); diff --git a/gdb/testsuite/gdb.mi/mi-reverse.exp b/gdb/testsuite/gdb.mi/mi-reverse.exp index baa53a495d7..0630b8b6c7f 100644 --- a/gdb/testsuite/gdb.mi/mi-reverse.exp +++ b/gdb/testsuite/gdb.mi/mi-reverse.exp @@ -96,11 +96,8 @@ proc test_controlled_execution_reverse {} { "reverse finish from callme" # Test exec-reverse-next - # It takes two steps to get back to the previous line, - # as the first step moves us to the start of the current line, - # and the one after that moves back to the previous line. - mi_execute_to "exec-next --reverse 2" \ + mi_execute_to "exec-next --reverse" \ "end-stepping-range" "main" "" \ "basics.c" $line_main_hello "" \ "reverse next to get over the call to do_nothing" diff --git a/gdb/testsuite/gdb.reverse/finish-reverse-next.exp b/gdb/testsuite/gdb.reverse/finish-reverse-next.exp index 1f53b649a7d..303f325eb18 100644 --- a/gdb/testsuite/gdb.reverse/finish-reverse-next.exp +++ b/gdb/testsuite/gdb.reverse/finish-reverse-next.exp @@ -76,14 +76,10 @@ gdb_continue_to_breakpoint \ repeat_cmd_until "stepi" "CALL VIA LEP" "{" "stepi into function1 call" "100" # The reverse-finish command should stop on the function call instruction -# which is the last instruction in the source code line. A reverse-next -# instruction should then stop at the first instruction in the same source -# code line. Another revers-next instruction stops at the previous source -# code line. +# which is the last instruction in the source code line. Another revers-next +# instruction stops at the previous source code line. gdb_test "reverse-finish" ".*function1 \\(a, b\\); // CALL VIA LEP.*" \ "reverse-finish function1 LEP call from LEP " -gdb_test "reverse-next" ".*function1 \\(a, b\\); // CALL VIA LEP" \ - "reverse next 1 LEP entry point function call from LEP" gdb_test "reverse-next" ".*b = 5;.*" "reverse next 2, at b = 5, call from LEP" @@ -109,14 +105,10 @@ gdb_continue_to_breakpoint \ gdb_test "step" ".*int ret = 0;.*" "step test 1" # The reverse-finish command should stop on the function call instruction -# which is the last instruction in the source code line. A reverse-next -# instruction should then stop at the first instruction in the same source -# code line. Another revers-next instruction stops at the previous source -# code line. +# which is the last instruction in the source code line. Another revers-next +# instruction stops at the previous source code line. gdb_test "reverse-finish" ".*function1 \\(a, b\\); // CALL VIA LEP.*" \ "reverse-finish function1 LEP call from function body" -gdb_test "reverse-next" ".*function1 \\(a, b\\); // CALL VIA LEP.*" \ - "reverse next 1 LEP from function body" gdb_test "reverse-next" ".*b = 5;.*" \ "reverse next 2 at b = 5, from function body" @@ -144,14 +136,11 @@ gdb_continue_to_breakpoint \ repeat_cmd_until "stepi" "CALL VIA GEP" "{" "stepi into funp call" # The reverse-finish command should stop on the function call instruction -# which is the last instruction in the source code line. A reverse-next -# instruction should then stop at the first instruction in the same source -# code line. Another revers-next instruction stops at the previous source -# code line. +# which is the last instruction in the source code line. Another revers-next +# instruction stops at the previous source code line. + gdb_test "reverse-finish" ".*funp \\(a, b\\);.*" \ "function1 GEP call call from GEP" -gdb_test "reverse-next" ".*funp \\(a, b\\);.*" \ - "reverse next 1 GEP entry point function call from GEP" gdb_test "reverse-next" ".*b = 50;.*" "reverse next 2 at b = 50, call from GEP" gdb_test "reverse-continue" ".*" "setup for test 4" @@ -180,14 +169,10 @@ repeat_cmd_until "stepi" "CALL VIA GEP" "{" "stepi into funp call again" gdb_test "stepi" "{" "stepi to between GEP and LEP" # The reverse-finish command should stop on the function call instruction -# which is the last instruction in the source code line. A reverse-next -# instruction should then stop at the first instruction in the same source -# code line. Another revers-next instruction stops at the previous source -# code line. +# which is the last instruction in the source code line. Another revers-next +# instruction stops at the previous source code line. gdb_test "reverse-finish" ".*funp \\(a, b\\);.*" \ "function1 GEP call call from GEP again" -gdb_test "reverse-next" ".*funp \\(a, b\\);.*" \ - "reverse next 1 GEP entry point function call from GEP again" gdb_test "reverse-next" ".*b = 50;.*" \ "reverse next 2 at b = 50, call from GEP again" @@ -212,13 +197,10 @@ gdb_continue_to_breakpoint \ gdb_test "step" ".*int ret = 0;.*" "step test 2" # The reverse-finish command should stop on the function call instruction -# which is the last instruction in the source code line. A reverse-next -# instruction should then stop at the first instruction in the same source -# code line. Another revers-next instruction stops at the previous source -# code line. +# which is the last instruction in the source code line. Another revers-next +# instruction stops at the previous source code line. gdb_test "reverse-finish" ".*funp \\(a, b\\);.*" \ "reverse-finish function1 GEP call, from function body " -gdb_test "reverse-next" ".*funp \\(a, b\\);.*" \ - "reverse next 1 GEP call from function body" + gdb_test "reverse-next" ".*b = 50;.*" \ "reverse next 2 at b = 50 from function body" diff --git a/gdb/testsuite/gdb.reverse/func-map-to-same-line.c b/gdb/testsuite/gdb.reverse/func-map-to-same-line.c new file mode 100644 index 00000000000..17fe17af267 --- /dev/null +++ b/gdb/testsuite/gdb.reverse/func-map-to-same-line.c @@ -0,0 +1,37 @@ +/* Copyright 2023 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see <http://www.gnu.org/licenses/>. + + This test is used to test the reverse-step and reverse-next instruction + execution for a source line that contains multiple function calls. */ + +void +func1 (void) +{ +} /* END FUNC1 */ + +void +func2 (void) +{ +} /* END FUNC2 */ + +int +main (void) +{ + int a, b; + a = 1; + b = 2; + func1 (); func2 (); + a = a + b; /* START REVERSE TEST */ +} diff --git a/gdb/testsuite/gdb.reverse/func-map-to-same-line.exp b/gdb/testsuite/gdb.reverse/func-map-to-same-line.exp new file mode 100644 index 00000000000..2890b5b1a70 --- /dev/null +++ b/gdb/testsuite/gdb.reverse/func-map-to-same-line.exp @@ -0,0 +1,139 @@ +# Copyright 2023 Free Software Foundation, Inc. + +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. */ + +# This file is part of the GDB testsuite. It tests reverse stepping. +# Lots of code borrowed from "step-test.exp". + +# This test checks to make sure there is no regression failures for +# the reverse-next command when stepping back over two functions in +# the same line. + +require supports_reverse + +# This test uses the gcc no-column-info command which was added in gcc 7.1. + +proc run_tests {} { + global testfile + + clean_restart ${testfile} + + if { ![runto_main] } { + return + } + + with_test_prefix "next-test" { + gdb_test_no_output "record" "turn on process record" + + # This regression test verifies the reverse-step and reverse-next + # commands work properly when executing backwards thru a source line + # containing two function calls on the same source line, i.e. func1 (); + # func2 ();. This test is compiled so the dwarf info not contain the + # line table information. + + # Test 1, reverse-next command + # Set breakpoint at the line after the function calls. + set bp_start_reverse_test [gdb_get_line_number "START REVERSE TEST"] + + gdb_breakpoint $bp_start_reverse_test temporary + + # Continue to break point for reverse-next test. + # Command definition: reverse-next [count] + # Run backward to the beginning of the previous line executed in the + # current (innermost) stack frame. If the line contains function + # calls,they will be “un-executed” without stopping. Starting from + # the first line of a function, reverse-next will take you back to + # the caller of that function, before the function was called, just + # as the normal next command would take you from the last line of a + # function back to its return to its caller 2 . + + gdb_continue_to_breakpoint \ + "stopped at command reverse-next test start location" \ + ".*$bp_start_reverse_test\r\n.*" + + # The reverse-next should step all the way back to the beginning of the + # line, i.e. at the beginning of the func1 call. + gdb_test "reverse-next" ".*func1 \\(\\); func2 \\(\\);.*" \ + " reverse-next to line with two functions" + + # We should be stopped at the first instruction of the line. A + # reverse-step should step back and stop at the beginning of the + # previous line b = 2, i.e. not in func1 (). + gdb_test "reverse-stepi" ".*b = 2;.*" \ + "reverse-stepi to previous line b = 2" + } + + # Setup for test 2 + clean_restart ${testfile} + + if { ![runto_main] } { + return + } + + with_test_prefix "step-test" { + gdb_test_no_output "record" "turn on process record" + + # Test 2, reverse-step command + # Set breakpoint at the line after the function calls. + gdb_breakpoint $bp_start_reverse_test temporary + + # Continue to the start of the reverse-step test. + # Command definition: reverse-step [count] + # Run the program backward until control reaches the start of a + # different source line; then stop it, and return control to gdb. + # Like the step command, reverse-step will only stop at the beginning + # of a source line. It “un-executes” the previously executed source + # line. If the previous source line included calls to debuggable + # functions, reverse-step will step (backward) into the called + # function, stopping at the beginning of the last statement in the + # called function (typically a return statement). Also, as with the + # step command, if non-debuggable functions are called, reverse-step + # will run thru them backward without stopping. + + gdb_continue_to_breakpoint \ + "stopped at command reverse-step test start location" \ + ".*$bp_start_reverse_test\r\n.*" + + # The first reverse step should take us call of func2 (). + gdb_test "reverse-step" ".*END FUNC2.*" \ + "reverse-step into func2 " + + # The second reverse step should take us into func1 (). + gdb_test "reverse-step" ".*END FUNC1.*" \ + "reverse-step into func1 " + + # The third reverse step should take us call of func1 (). + gdb_test "reverse-step" ".*func1 \\(\\); func2 \\(\\);.*" \ + "reverse-step to line func1(); func2(), at call for func1 " + + # We should be stopped at the first instruction of the line. A reverse + # stepi should take us to b = 2 (). + gdb_test "reverse-stepi" ".*b = 2;.*" \ + "reverse-stepi to line b = 2 " + } +} + +standard_testfile .c + +# test with and without gcc column info enabled +foreach_with_prefix column_info_flag {column-info no-column-info} { + set options [list debug $column_info_flag] + + if {[prepare_for_testing "failed to prepare" ${testfile} ${srcfile} \ + $options]} { + return -1 + } + + run_tests +} diff --git a/gdb/testsuite/gdb.reverse/map-to-same-line.c b/gdb/testsuite/gdb.reverse/map-to-same-line.c new file mode 100644 index 00000000000..5ae0a89b329 --- /dev/null +++ b/gdb/testsuite/gdb.reverse/map-to-same-line.c @@ -0,0 +1,58 @@ +/* Copyright 2023 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see <http://www.gnu.org/licenses/ >. */ + +/* The purpose of this test is to create a DWARF line table that contains two + or more entries for the same line. When stepping (forwards or backwards), + GDB should step over the entire line and not just a particular entry in the + line table. */ + +int +main (void) +{ /* TAG: main prologue */ + asm ("main_label: .globl main_label"); + int i = 1, j = 2, k; + float f1 = 2.0, f2 = 4.1, f3; + const char *str_1 = "foo", *str_2 = "bar", *str_3; + + asm ("line1: .globl line1"); + k = i; f3 = f1; str_3 = str_1; /* TAG: line 1 */ + + asm ("line2: .globl line2"); + k = j; f3 = f2; str_3 = str_2; /* TAG: line 2 */ + + asm ("line3: .globl line3"); + k = i; f3 = f1; str_3 = str_1; /* TAG: line 3 */ + + asm ("line4: .globl line4"); + k = j; f3 = f2; str_3 = str_2; /* TAG: line 4 */ + + asm ("line5: .globl line5"); + k = i; f3 = f1; str_3 = str_1; /* TAG: line 5 */ + + asm ("line6: .globl line6"); + k = j; f3 = f2; str_3 = str_2; /* TAG: line 6 */ + + asm ("line7: .globl line7"); + k = i; f3 = f1; str_3 = str_1; /* TAG: line 7 */ + + asm ("line8: .globl line8"); + k = j; f3 = f2; str_3 = str_2; /* TAG: line 8 */ + + asm ("main_return: .globl main_return"); + k = j; f3 = f2; str_3 = str_2; /* TAG: main return */ + + asm ("end_of_sequence: .globl end_of_sequence"); + return 0; /* TAG: main return */ +} diff --git a/gdb/testsuite/gdb.reverse/map-to-same-line.exp b/gdb/testsuite/gdb.reverse/map-to-same-line.exp new file mode 100644 index 00000000000..63f8c9c76b3 --- /dev/null +++ b/gdb/testsuite/gdb.reverse/map-to-same-line.exp @@ -0,0 +1,153 @@ +# Copyright 2023 Free Software Foundation, Inc. + +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/ >. + +# When stepping (forwards or backwards), GDB should step over the entire line +# and not just a particular entry in the line table. This test was added to +# verify the find_line_range_start function properly sets the step range for a +# line that consists of multiple statements, i.e. multiple entries in the line +# table. This test creates a DWARF line table that contains two entries for +# the same line to do the needed testing. + +# This test can only be run on targets which support DWARF-2 and use gas. +load_lib dwarf.exp +require dwarf2_support + +# The DWARF assembler requires the gcc compiler. +require is_c_compiler_gcc + +# This test suitable only for process that can do reverse execution +require supports_reverse + +standard_testfile .c .S + +if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile}] } { + return -1 +} + +set asm_file [standard_output_file $srcfile2] +Dwarf::assemble $asm_file { + global srcdir subdir srcfile + declare_labels integer_label L + + # Find start address and length of program + lassign [function_range main [list ${srcdir}/${subdir}/$srcfile]] \ + main_start main_len + set main_end "$main_start + $main_len" + + cu {} { + compile_unit { + {language @DW_LANG_C} + {name map-to-same-line.c} + {stmt_list $L DW_FORM_sec_offset} + {low_pc 0 addr} + } { + subprogram { + {external 1 flag} + {name main} + {low_pc $main_start addr} + {high_pc $main_len DW_FORM_data4} + } + } + } + + lines {version 2 default_is_stmt 1} L { + include_dir "${srcdir}/${subdir}" + file_name "$srcfile" 1 + + # Generate the line table program with distinct source lines being + # mapped to the same line entry. Line 1, 5 and 8 contain 1 statement + # each. Line 2 contains 2 statements. Line 3 contains 3 statements. + program { + DW_LNE_set_address $main_start + line [gdb_get_line_number "TAG: main prologue"] + DW_LNS_copy + DW_LNE_set_address line1 + line [gdb_get_line_number "TAG: line 1" ] + DW_LNS_copy + DW_LNE_set_address line2 + line [gdb_get_line_number "TAG: line 2" ] + DW_LNS_copy + DW_LNE_set_address line3 + line [gdb_get_line_number "TAG: line 2" ] + DW_LNS_copy + DW_LNE_set_address line4 + line [gdb_get_line_number "TAG: line 3" ] + DW_LNS_copy + DW_LNE_set_address line5 + line [gdb_get_line_number "TAG: line 3" ] + DW_LNS_copy + DW_LNE_set_address line6 + line [gdb_get_line_number "TAG: line 3" ] + DW_LNS_copy + DW_LNE_set_address line7 + line [gdb_get_line_number "TAG: line 5" ] + DW_LNS_copy + DW_LNE_set_address line8 + line [gdb_get_line_number "TAG: line 8" ] + DW_LNS_copy + DW_LNE_set_address main_return + line [gdb_get_line_number "TAG: main return"] + DW_LNS_copy + DW_LNE_set_address end_of_sequence + DW_LNE_end_sequence + } + } +} + +if { [prepare_for_testing "failed to prepare" ${testfile} \ + [list $srcfile $asm_file] {nodebug} ] } { + return -1 +} + +if { ![runto_main] } { + return +} + +# Print the line table +gdb_test_multiple "maint info line-table ${testfile}" "" { + -re "\r\n$decimal\[ \t\]+$decimal\[ \t\]+($hex)\[ \t\]+Y\[^\r\n\]*" { + lappend is_stmt $expect_out(1,string) + exp_continue + } + -re -wrap "" { + } +} + +# Do the reverse-step and reverse-next tests +foreach_with_prefix cmd {step next} { + gdb_test_no_output "record" "turn on process record, test $cmd" + + set bp_main_return [gdb_get_line_number "TAG: main return" $srcfile] + gdb_breakpoint $srcfile:$bp_main_return + gdb_continue_to_breakpoint "run to end of main, reverse-$cmd test" ".*$srcfile:$bp_main_return.*" + gdb_test "display \$pc" ".*pc =.*" "display pc, reverse-$cmd test" + + # At this point, GDB has already recorded the execution up until the return + # statement. Reverse and test if GDB transitions between lines in the + # expected order. It should reverse-step or reverse-next across lines 8, + # 5, 3, 2 and 1. + foreach line {8 5 3 2 1} { + gdb_test "reverse-$cmd" ".*TAG: line $line.*" "reverse $cmd to line $line" + } + + if {$cmd =="step"} { + ## Clean restart, test reverse-next command + clean_restart ${testfile} + + if { ![runto_main] } { + return + } + } +} -- 2.37.2 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2 ver 7] Fix reverse stepping multiple contiguous PC ranges over the line table. 2023-08-07 19:03 ` [PATCH 2/2 ver 7] " Carl Love @ 2023-08-08 14:14 ` Guinevere Larsen 2023-08-08 15:52 ` Carl Love 0 siblings, 1 reply; 13+ messages in thread From: Guinevere Larsen @ 2023-08-08 14:14 UTC (permalink / raw) To: Carl Love, Simon Marchi, gdb-patches, UlrichWeigand, pedro; +Cc: luis.machado On 07/08/2023 21:03, Carl Love wrote: > > Bruno, Simon, GDB maintainers: Heads up, I go by Guinevere now, no longer Bruno :) Other than that, I have a very minor nit inlined, but you can take or leave that one, honestly. Reviewed-By: Guinevere Larsen <blarsen@redhat.com> > > Version 7, addressed behavior of GDB when stepping backward thru a > function call as mentioned by Bruno. GDB would stop at the function > call and then a reverse step/next would cause GDB to stop at the first > instruction of the same line as the function call instead of stopping > in the previous line. The behavior was fixed and the various test > programs were updated to remove one of the two reverse step or next > instructions required to reach the previous line. > > Version 6, fixed various code style issues in the GDB source. The > testcases were updated to use with_test_prefix for each gdb test in the > step and next test cases, switch using the standard_testfile, use > foreach_with_prefix to combine otherwise identical tests. Retested on > Power 10. > > Version 5, changed comments in test case func-map-to-same-line.c. > Patch 1/2 implemented the new options for gdb_compile. Updated the > call to proc run_tests to use the new gdb_compile options in a > foreach_with_prefix loop. > > Version 4, additional fixes for gcc version check, wrap function calls > using "with_test_prefix", move load_lib dwarf.exe. Fixed typo noted by > Luis. > > Version 3, added the gcc version check as discussed further from > version 2 of the patch. Also updated the tests to check for supporting > reverse execution rather than requiring recording. I also noticed > there were a couple more instances of a requirement check, i.e. if [] > which I changed to "require" per the current style for checking on the > test requirements. > > > The following patch fixes issues on PowerPC with the reverse-step and > reverse-next instructions when there are multiple assignment statements > on the same line and when there are multiple function calls on the same > line. The commit log below discusses these issues in further depth. > The discussion included what the correct operation should be for these > commands based on the GDB documentation. The proposed patch at that > time changed how the commands worked on other platforms such as X86 in > a way they no longer matched the documentation. > > The issue is the line table contains multiple entries for the same > source line. The patch adds a function to search the line table to > find the address of the first instruction of a line. When setup up the > reverse stepping range, the function is called to make sure the start > of the range corresponds to the address of the first instruction for > the line. This approach was used. When Luis initially developed the > patch, he considered merging the contiguous ranges in the line table > when reading the line tables. He decided it was better to work with the > data directly in the line table rather than creating and using a > modified version of the line table. > > The following patch fixes the execution of the reveres-step and > reverse-next commands for both senarios of multiple statements on the > same line for PowerPC and aarch64-linux. Unlike the previous patch, it > does not change the operation of the commands on other platforms, i.e. > X86. The patch adds new test cases for both scenarios to verify they > work correctly. > > The patch has been tested on PowerPC, Intel X86 and aarch64-linux with > no new regression failures. > > Please let me know if the patch is acceptable for mainline. Thanks. > > Carl > > > > -------------------------------- > Fix reverse stepping multiple contiguous PC ranges over the line table. > > There are a couple of scenarios where the GDB reverse-step and reverse-next > commands do not work correctly. > > Scenario 1 issue description by Luis Machado: > > When running GDB's testsuite on aarch64-linux/Ubuntu 20.04 (also spotted on > the ppc backend), I noticed some failures in gdb.reverse/solib-precsave.exp > and gdb.reverse/solib-reverse.exp. > > The failure happens around the following code: > > 38 b[1] = shr2(17); /* middle part two */ > 40 b[0] = 6; b[1] = 9; /* generic statement, end part two */ > 42 shr1 ("message 1\n"); /* shr1 one */ > > Normal execution: > > - step from line 38 will land on line 40. > - step from line 40 will land on line 42. > > Reverse execution: > - step from line 42 will land on line 40. > - step from line 40 will land on line 40. > - step from line 40 will land on line 38. > > V > The problem here is that line 40 contains two contiguous but distinct > PC ranges in the line table, like so: > > Line 40 - [0x7ec ~ 0x7f4] > Line 40 - [0x7f4 ~ 0x7fc] > > The two distinct ranges are generated because GCC started outputting source > column information, which GDB doesn't take into account at the moment. > > When stepping forward from line 40, we skip both of these ranges and land on > line 42. When stepping backward from line 42, we stop at the start PC of the > second (or first, going backwards) range of line 40. > > Since we've reached ecs->event_thread->control.step_range_start, we stop > stepping backwards. > > --------------------------------------------------------- > > Scenario 2 issue described by Pedro Alves: > > The following explanation of the issue was taken from the gdb mailing list > discussion of the withdrawn patch to change the behavior of the reverse-step > and reverse-next commands. Specifically, message from Pedro Alves > <pedro@palves.net> where he demonstrates the issue where you have multiple > function calls on the same source code line: > > https://sourceware.org/pipermail/gdb-patches/2023-January/196110.html > > The source line looks like: > > func1 (); func2 (); > > so stepping backwards over that line should always stop at the first > instruction of the line, not in the middle. Let's simplify this. > > Here's the full source code of my example: > > (gdb) list 1 > 1 void func1 () > 2 { > 3 } > 4 > 5 void func2 () > 6 { > 7 } > 8 > 9 int main () > 10 { > 11 func1 (); func2 (); > 12 } > > Compiled with: > > $ gcc reverse.c -o reverse -g3 -O0 > $ gcc -v > ... > gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04) > > Now let's debug it with target record, using current gdb git master (f3d8ae90b236), > without your patch: > > $ gdb ~/reverse > GNU gdb (GDB) 14.0.50.20230124-git > ... > Reading symbols from /home/pedro/reverse... > (gdb) start > Temporary breakpoint 1 at 0x1147: file reverse.c, line 11. > Starting program: /home/pedro/reverse > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > > Temporary breakpoint 1, main () at reverse.c:11 > 11 func1 (); func2 (); > (gdb) record > > (gdb) disassemble /s > Dump of assembler code for function main: > reverse.c: > 10 { > 0x000055555555513f <+0>: endbr64 > 0x0000555555555143 <+4>: push %rbp > 0x0000555555555144 <+5>: mov %rsp,%rbp > > 11 func1 (); func2 (); > => 0x0000555555555147 <+8>: mov $0x0,%eax > 0x000055555555514c <+13>: call 0x555555555129 <func1> > 0x0000555555555151 <+18>: mov $0x0,%eax > 0x0000555555555156 <+23>: call 0x555555555134 <func2> > 0x000055555555515b <+28>: mov $0x0,%eax > > 12 } > 0x0000555555555160 <+33>: pop %rbp > 0x0000555555555161 <+34>: ret > End of assembler dump. > > (gdb) n > 12 } > > So far so good, a "next" stepped over the whole of line 11 and stopped at line 12. > > Let's confirm where we are now: > > (gdb) disassemble /s > Dump of assembler code for function main: > reverse.c: > 10 { > 0x000055555555513f <+0>: endbr64 > 0x0000555555555143 <+4>: push %rbp > 0x0000555555555144 <+5>: mov %rsp,%rbp > > 11 func1 (); func2 (); > 0x0000555555555147 <+8>: mov $0x0,%eax > 0x000055555555514c <+13>: call 0x555555555129 <func1> > 0x0000555555555151 <+18>: mov $0x0,%eax > 0x0000555555555156 <+23>: call 0x555555555134 <func2> > 0x000055555555515b <+28>: mov $0x0,%eax > > 12 } > => 0x0000555555555160 <+33>: pop %rbp > 0x0000555555555161 <+34>: ret > End of assembler dump. > > Good, we're at the first instruction of line 12. > > Now let's undo the "next", with "reverse-next": > > (gdb) reverse-next > 11 func1 (); func2 (); > > Seemingly stopped at line 11. Let's see exactly where: > > (gdb) disassemble /s > Dump of assembler code for function main: > reverse.c: > 10 { > 0x000055555555513f <+0>: endbr64 > 0x0000555555555143 <+4>: push %rbp > 0x0000555555555144 <+5>: mov %rsp,%rbp > > 11 func1 (); func2 (); > 0x0000555555555147 <+8>: mov $0x0,%eax > 0x000055555555514c <+13>: call 0x555555555129 <func1> > => 0x0000555555555151 <+18>: mov $0x0,%eax > 0x0000555555555156 <+23>: call 0x555555555134 <func2> > 0x000055555555515b <+28>: mov $0x0,%eax > > 12 } > 0x0000555555555160 <+33>: pop %rbp > 0x0000555555555161 <+34>: ret > End of assembler dump. > (gdb) > > And lo, we stopped in the middle of line 11! That is a bug, we should have > stepped back all the way to the beginning of the line. The "reverse-next" > should have fully undone the prior "next" command. > > The above issues were fixed by introducing a new function that looks for > adjacent PC ranges for the same line, until we notice a line change. Then > we take that as the start PC of the range. The new start PC for the range > is used for the control.step_range_start when setting up a step range. > > The test case gdb.reverse/map-to-same-line.exp is added to test the fix > for the issues in scenario 1. > > The test case gdb.reverse/func-map-to-same-line.exp was added to test the > fix for scenario 2 when the binary was compiled with and without line > table information. > > bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28426 > > Co-authored-by: Luis Machado <luis.machado@arm.com> > Co-authored-by: Carl Love <cel@us.ibm.com> > --- > gdb/infcmd.c | 13 ++ > gdb/infrun.c | 59 +++++++ > gdb/symtab.c | 49 ++++++ > gdb/symtab.h | 16 ++ > gdb/testsuite/gdb.mi/mi-reverse.exp | 5 +- > .../gdb.reverse/finish-reverse-next.exp | 42 ++--- > .../gdb.reverse/func-map-to-same-line.c | 37 +++++ > .../gdb.reverse/func-map-to-same-line.exp | 139 ++++++++++++++++ > gdb/testsuite/gdb.reverse/map-to-same-line.c | 58 +++++++ > .../gdb.reverse/map-to-same-line.exp | 153 ++++++++++++++++++ > 10 files changed, 537 insertions(+), 34 deletions(-) > create mode 100644 gdb/testsuite/gdb.reverse/func-map-to-same-line.c > create mode 100644 gdb/testsuite/gdb.reverse/func-map-to-same-line.exp > create mode 100644 gdb/testsuite/gdb.reverse/map-to-same-line.c > create mode 100644 gdb/testsuite/gdb.reverse/map-to-same-line.exp > > diff --git a/gdb/infcmd.c b/gdb/infcmd.c > index 15702f84894..add0eadd8c1 100644 > --- a/gdb/infcmd.c > +++ b/gdb/infcmd.c > @@ -982,6 +982,19 @@ prepare_one_step (thread_info *tp, struct step_command_fsm *sm) > &tp->control.step_range_start, > &tp->control.step_range_end); > > + if (execution_direction == EXEC_REVERSE) > + { > + symtab_and_line sal = find_pc_line (pc, 0); > + symtab_and_line sal_start > + = find_pc_line (tp->control.step_range_start, 0); > + > + if (sal.line == sal_start.line) > + /* Executing in reverse, the step_range_start address is in > + the same line. We want to stop in the previous line so > + move step_range_start before the current line. */ > + tp->control.step_range_start--; > + } > + > /* There's a problem in gcc (PR gcc/98780) that causes missing line > table entries, which results in a too large stepping range. > Use inlined_subroutine info to make the range more narrow. */ > diff --git a/gdb/infrun.c b/gdb/infrun.c > index 8286026e6c6..32ba852f227 100644 > --- a/gdb/infrun.c > +++ b/gdb/infrun.c > @@ -115,6 +115,9 @@ static struct async_event_handler *infrun_async_inferior_event_token; > Starts off as -1, indicating "never enabled/disabled". */ > static int infrun_is_async = -1; > > +static CORE_ADDR update_line_range_start (CORE_ADDR pc, > + struct execution_control_state *ecs); > + > /* See infrun.h. */ > > void > @@ -6884,6 +6887,27 @@ handle_signal_stop (struct execution_control_state *ecs) > process_event_stop_test (ecs); > } > > +/* Return the address for the beginning of the line. */ > + > +CORE_ADDR > +update_line_range_start (CORE_ADDR pc, struct execution_control_state *ecs) > +{ > + /* The line table may have multiple entries for the same source code line. > + Given the PC, check the line table and return the PC that corresponds > + to the line table entry for the source line that PC is in. */ > + CORE_ADDR start_line_pc = ecs->event_thread->control.step_range_start; > + gdb::optional<CORE_ADDR> real_range_start; > + > + /* Call find_line_range_start to get the smallest address in the > + linetable for multiple Line X entries in the line table. */ > + real_range_start = find_line_range_start (pc); > + > + if (real_range_start.has_value ()) > + start_line_pc = *real_range_start; > + > + return start_line_pc; > +} > + > /* Come here when we've got some debug event / signal we can explain > (IOW, not a random signal), and test whether it should cause a > stop, or whether we should resume the inferior (transparently). > @@ -7685,6 +7709,28 @@ process_event_stop_test (struct execution_control_state *ecs) > > if (stop_pc_sal.is_stmt) > { > + if (execution_direction == EXEC_REVERSE) > + { > + /* We are stepping backwards make sure we have reached the > + beginning of the line. */ > + CORE_ADDR stop_pc = ecs->event_thread->stop_pc (); > + CORE_ADDR start_line_pc > + = update_line_range_start (stop_pc, ecs); > + > + if (stop_pc != start_line_pc) > + { > + /* Have not reached the beginning of the source code line. > + Set a step range. Execution should stop in any function > + calls we execute back into before reaching the beginning > + of the line. */ > + ecs->event_thread->control.step_range_start = start_line_pc; > + ecs->event_thread->control.step_range_end = stop_pc; > + set_step_info (ecs->event_thread, frame, stop_pc_sal); > + keep_going (ecs); > + return; > + } > + } > + > /* We are at the start of a statement. > > So stop. Note that we don't stop if we step into the middle of a > @@ -7747,6 +7793,19 @@ process_event_stop_test (struct execution_control_state *ecs) > set_step_info (ecs->event_thread, frame, stop_pc_sal); > > infrun_debug_printf ("keep going"); > + > + if (execution_direction == EXEC_REVERSE) > + { > + CORE_ADDR stop_pc = ecs->event_thread->stop_pc (); > + > + /* Make sure the stop_pc is set to the beginning of the line. */ > + if (stop_pc != ecs->event_thread->control.step_range_start) > + { > + stop_pc = update_line_range_start (stop_pc, ecs); > + ecs->event_thread->control.step_range_start = stop_pc; pretty small nit, but I think it is better to just use ecs->event_thread->control.step_range_start = update_line_range_start (stop_pc, ecs); Just because it is kind of weird, to see the step_range_start being set to stop pc, and made me do a double take :) -- Cheers, Guinevere Larsen She/Her/Hers ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [PATCH 2/2 ver 7] Fix reverse stepping multiple contiguous PC ranges over the line table. 2023-08-08 14:14 ` Guinevere Larsen @ 2023-08-08 15:52 ` Carl Love 0 siblings, 0 replies; 13+ messages in thread From: Carl Love @ 2023-08-08 15:52 UTC (permalink / raw) To: Guinevere Larsen, Simon Marchi, gdb-patches, UlrichWeigand, pedro Cc: luis.machado, cel Guinevere: On Tue, 2023-08-08 at 16:14 +0200, Guinevere Larsen wrote: > > infrun_debug_printf ("keep going"); > > + > > + if (execution_direction == EXEC_REVERSE) > > + { > > + CORE_ADDR stop_pc = ecs->event_thread->stop_pc (); > > + > > + /* Make sure the stop_pc is set to the beginning of the > > line. */ > > + if (stop_pc != ecs->event_thread->control.step_range_start) > > + { > > + stop_pc = update_line_range_start (stop_pc, ecs); > > + ecs->event_thread->control.step_range_start = stop_pc; > pretty small nit, but I think it is better to just use > > ecs->event_thread->control.step_range_start > = update_line_range_start (stop_pc, ecs); > > Just because it is kind of weird, to see the step_range_start being > set > to stop pc, and made me do a double take :) > Yea, I may have done it like that to make it easier to print the new stop_pc value when developing the patch. Honestly, at this point I don't recall for sure. Anyway, I updated the code as follows: if (execution_direction == EXEC_REVERSE) { CORE_ADDR stop_pc = ecs->event_thread->stop_pc (); /* Make sure the stop_pc is set to the beginning of the line. */ if (stop_pc != ecs->event_thread->control.step_range_start) ecs->event_thread->control.step_range_start = update_line_range_start (stop_pc, ecs); } keep_going (ecs); I made the change locally and will include it in any future versions/commits. Not sure it is worth sending out a new version with the change at the moment. Lets see if I get any additional comments from the community first. Thanks for mentioning that. Carl ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 0/2] Fix reverse stepping multiple contiguous PC ranges over the line table.
@ 2023-08-25 15:50 Carl Love
2023-08-29 12:28 ` Guinevere Larsen
0 siblings, 1 reply; 13+ messages in thread
From: Carl Love @ 2023-08-25 15:50 UTC (permalink / raw)
To: Simon Marchi, blarsen, gdb-patches, UlrichWeigand, pedro
Cc: luis.machado, cel
GDB maintainers:
I received a few messages from Guinevere about these two patches. In
the end, we agreed the first patch was OK. There was a minor code
change suggested for the second patch that I have implemented. Since I
have not received any additional suggestions on the second patch, it is
time to ping the first patch and post the updated second patch for
review.
The first patch in the series has not been changed. I am reposting it
along with the second patch so it doesn't get lost.
The patch series has been tested on Power10 LE and on X86-64.
Please let me know if these two patches are acceptable for mainline.
Thanks.
Carl
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 0/2] Fix reverse stepping multiple contiguous PC ranges over the line table. 2023-08-25 15:50 [PATCH 0/2] " Carl Love @ 2023-08-29 12:28 ` Guinevere Larsen 2023-08-29 18:55 ` Carl Love 0 siblings, 1 reply; 13+ messages in thread From: Guinevere Larsen @ 2023-08-29 12:28 UTC (permalink / raw) To: Carl Love, Simon Marchi, gdb-patches, UlrichWeigand, pedro; +Cc: luis.machado On 25/08/2023 17:50, Carl Love wrote: > GDB maintainers: > > I received a few messages from Guinevere about these two patches. In > the end, we agreed the first patch was OK. There was a minor code > change suggested for the second patch that I have implemented. Since I > have not received any additional suggestions on the second patch, it is > time to ping the first patch and post the updated second patch for > review. > > The first patch in the series has not been changed. I am reposting it > along with the second patch so it doesn't get lost. > > The patch series has been tested on Power10 LE and on X86-64. > > Please let me know if these two patches are acceptable for mainline. > Thanks. > > Carl > I have tested this patch with both GCC and Clang. I can verify it fixes the issue, adds no regression, and even fixes the final issues when testing gdb.reverse with clang! Tested-By: Guinevere Larsen <blarsen@redhat.com> -- Cheers, Guinevere Larsen She/Her/Hers ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [PATCH 0/2] Fix reverse stepping multiple contiguous PC ranges over the line table. 2023-08-29 12:28 ` Guinevere Larsen @ 2023-08-29 18:55 ` Carl Love 2023-09-05 15:12 ` Carl Love 0 siblings, 1 reply; 13+ messages in thread From: Carl Love @ 2023-08-29 18:55 UTC (permalink / raw) To: Guinevere Larsen, Simon Marchi, gdb-patches, UlrichWeigand, pedro Cc: luis.machado, cel Guinevere: On Tue, 2023-08-29 at 14:28 +0200, Guinevere Larsen wrote: > I have tested this patch with both GCC and Clang. I can verify it > fixes > the issue, adds no regression, and even fixes the final issues when > testing gdb.reverse with clang! > > Tested-By: Guinevere Larsen <blarsen@redhat.com> Thanks for the help testing and that it fixes the clang failures for test gdb.reverse. Carl ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [PATCH 0/2] Fix reverse stepping multiple contiguous PC ranges over the line table. 2023-08-29 18:55 ` Carl Love @ 2023-09-05 15:12 ` Carl Love 2023-09-25 22:15 ` Carl Love 0 siblings, 1 reply; 13+ messages in thread From: Carl Love @ 2023-09-05 15:12 UTC (permalink / raw) To: Guinevere Larsen, Simon Marchi, gdb-patches, UlrichWeigand, pedro Cc: luis.machado GDB maintainers: Ping. I was wondering if anyoneany of the maintainers has had time to review these patches? Thanks for your time and effort on the patch. On Tue, 2023-08-29 at 11:55 -0700, Carl Love wrote: > Guinevere: > > On Tue, 2023-08-29 at 14:28 +0200, Guinevere Larsen wrote: > > I have tested this patch with both GCC and Clang. I can verify it > > fixes > > the issue, adds no regression, and even fixes the final issues > > when > > testing gdb.reverse with clang! > > > > Tested-By: Guinevere Larsen <blarsen@redhat.com> Carl ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: [PATCH 0/2] Fix reverse stepping multiple contiguous PC ranges over the line table. 2023-09-05 15:12 ` Carl Love @ 2023-09-25 22:15 ` Carl Love 0 siblings, 0 replies; 13+ messages in thread From: Carl Love @ 2023-09-25 22:15 UTC (permalink / raw) To: Guinevere Larsen, Simon Marchi, gdb-patches, UlrichWeigand, pedro Cc: luis.machado, cel GDB maintainers: Ping. On Tue, 2023-09-05 at 08:12 -0700, Carl Love wrote: > GDB maintainers: > > Ping. I was wondering if anyoneany of the maintainers has had time > to > review these patches? Thanks for your time and effort on the patch. > > On Tue, 2023-08-29 at 11:55 -0700, Carl Love wrote: > > Guinevere: > > > > On Tue, 2023-08-29 at 14:28 +0200, Guinevere Larsen wrote: > > > I have tested this patch with both GCC and Clang. I can verify it > > > fixes > > > the issue, adds no regression, and even fixes the final issues > > > when > > > testing gdb.reverse with clang! > > > > > > Tested-By: Guinevere Larsen <blarsen@redhat.com> > > Carl ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2023-09-25 22:15 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-08-07 18:54 [PATCH 0/2] Fix reverse stepping multiple contiguous PC ranges over the line table Carl Love 2023-08-07 19:03 ` [PATCH 1/2 ver 2] " Carl Love 2023-08-08 10:04 ` Guinevere Larsen 2023-08-08 15:38 ` Carl Love 2023-08-08 15:45 ` Guinevere Larsen 2023-08-07 19:03 ` [PATCH 2/2 ver 7] " Carl Love 2023-08-08 14:14 ` Guinevere Larsen 2023-08-08 15:52 ` Carl Love 2023-08-25 15:50 [PATCH 0/2] " Carl Love 2023-08-29 12:28 ` Guinevere Larsen 2023-08-29 18:55 ` Carl Love 2023-09-05 15:12 ` Carl Love 2023-09-25 22:15 ` Carl Love
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).