* Questions on how best to fix two gdb tests gdb.reverse/finish-reverse-bkpt.exp and gdb.reverse/next-reverse-bkpt-over-sr.exp @ 2022-09-22 18:23 Carl Love 2022-09-23 9:13 ` Bruno Larsen 2022-09-23 10:48 ` Luis Machado 0 siblings, 2 replies; 7+ messages in thread From: Carl Love @ 2022-09-22 18:23 UTC (permalink / raw) To: gdb-patches; +Cc: Will Schmidt, cel, Ulrich Weigand, Pedro Alves, Pedro Alves GDB community: There are two gdb tests gdb.reverse/finish-reverse-bkpt.exp and gdb.reverse/next-reverse-bkpt-over-sr.exp which fail for similar reasons on PowerPC. It appears to me that the issues are with the tests and not with gdb itself. Both tests set breakpoints on *func where func is a function in the source file. This is the fundamental issue with both tests. The test gdb.reverse/finish-reverse-bkpt.exp has the comment: gdb_test "tbreak void_func" \ "Temporary breakpoint $decimal at .*$srcfile, line $breakloc\." \ "set breakpoint on void_func" gdb_continue_to_breakpoint "void_func" ".*$srcfile:$breakloc.*" # We stop at the brekapoint on void_func, but breakpoint on # *void_func will be set at the same place if function void_func doesn't # have prologue. One step forward to avoid this. gdb_test "si" gdb_test "break \*void_func" \ "Breakpoint $decimal at .*" \ "set breakpoint at void_func's entry" The comment about break point on void_func and breakpoint on *void_func being the same if there is no prolong is not true for all architectures. Specifically PowerPC uses local and global entry points. The statement "break *foo" sets the breakpoint at the address of the first instruction in the function where as "break foo" sets the breakpoint at the beginning of the function, i.e. after the prolog following the local entry point. Specifically for this test the PowerPC assembly code is as follows: void void_func () { 1000068c: 02 10 40 3c lis r2,4098 <-global entry point, location of break *void_func 10000690: 00 7f 42 38 addi r2,r2,32512 10000694: f8 ff e1 fb std r31,-8(r1) <-local entry point 10000698: d1 ff 21 f8 stdu r1,-48(r1) <-prolog 1000069c: 78 0b 3f 7c mr r31,r1 <-prolog void_test = 1; /* VOID FUNC */ 100006a0: 00 00 00 60 nop <- location of break void_func 100006a4: 58 81 22 39 addi r9,r2,-32424 100006a8: 01 00 40 39 li r10,1 .... The test fails on PowerPC because the reverse execution never hits the breakpoint at *void_func because the function is called using the local entry point. Thus gdb returns to the caller after it reaches the local entry point at address 10000694. It does not continue executing back to the global entry point. The global entry point is only used in special cases when the Table of Contents (TOC) pointer is not already setup in r2. The question is how to fix the test in general? 1) Changing the breakpoint on *void_func to void_func will cause both breakpoints to be the same regardless if there is a prolog. That change would seem to invalidate the point of the test? 2) Disable the test for architectures where the assumption breakpoint on foo and breakpoint on *foo is the same except for a prolog. The downside is we are missing testing of some gdb functionality. Is there another way to fix this test to run correctly on PowerPC? The test gdb.reverse/next-reverse-bkpt-over-sr.exp also fails because it does a break on *callee. Specifically, set lineno [gdb_get_line_number "STEP INTO THIS CALL"] gdb_test "advance $lineno" ".*STEP INTO THIS CALL.*" "get past callee call" gdb_test "b \*callee" "" "set breakpoint at callee's entry" set bpnum [get_integer_valueof "\$bpnum" 0] gdb_test "reverse-next" \ "Breakpoint $bpnum, callee.*" \ "reverse-next over call trips user breakpoint at function entry" gdb_test "up" \ ".*NEXT OVER THIS CALL.*" \ "stopped at the right callee call" In this case, it looks to me like changing the gdb_test to callee instead of *callee doesn't break the point of the test. Making the change on PowerPC fixes the test. Does anyone see any issues with changing the breakpoint from *callee to calle for this test? Thanks for the input and help fixing these tests on PowerPC. Carl Love ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Questions on how best to fix two gdb tests gdb.reverse/finish-reverse-bkpt.exp and gdb.reverse/next-reverse-bkpt-over-sr.exp 2022-09-22 18:23 Questions on how best to fix two gdb tests gdb.reverse/finish-reverse-bkpt.exp and gdb.reverse/next-reverse-bkpt-over-sr.exp Carl Love @ 2022-09-23 9:13 ` Bruno Larsen 2022-09-23 10:48 ` Luis Machado 1 sibling, 0 replies; 7+ messages in thread From: Bruno Larsen @ 2022-09-23 9:13 UTC (permalink / raw) To: gdb-patches On 22/09/2022 20:23, Carl Love via Gdb-patches wrote: > GDB community: > > There are two gdb tests gdb.reverse/finish-reverse-bkpt.exp and > gdb.reverse/next-reverse-bkpt-over-sr.exp which fail for similar > reasons on PowerPC. It appears to me that the issues are with the > tests and not with gdb itself. Both tests set breakpoints on *func > where func is a function in the source file. This is the fundamental > issue with both tests. > > The test gdb.reverse/finish-reverse-bkpt.exp has the comment: > > gdb_test "tbreak void_func" \ > "Temporary breakpoint $decimal at .*$srcfile, line $breakloc\." \ > "set breakpoint on void_func" > gdb_continue_to_breakpoint "void_func" ".*$srcfile:$breakloc.*" > > # We stop at the brekapoint on void_func, but breakpoint on > # *void_func will be set at the same place if function void_func doesn't > # have prologue. One step forward to avoid this. > gdb_test "si" > > gdb_test "break \*void_func" \ > "Breakpoint $decimal at .*" \ > "set breakpoint at void_func's entry" > > The comment about break point on void_func and breakpoint on *void_func > being the same if there is no prolong is not true for all > architectures. Specifically PowerPC uses local and global entry > points. The statement "break *foo" sets the breakpoint at the address > of the first instruction in the function where as "break foo" sets the > breakpoint at the beginning of the function, i.e. after the prolog > following the local entry point. Specifically for this test the > PowerPC assembly code is as follows: > > void void_func () > { > 1000068c: 02 10 40 3c lis r2,4098 <-global entry point, > location of break *void_func > 10000690: 00 7f 42 38 addi r2,r2,32512 > 10000694: f8 ff e1 fb std r31,-8(r1) <-local entry point > 10000698: d1 ff 21 f8 stdu r1,-48(r1) <-prolog > 1000069c: 78 0b 3f 7c mr r31,r1 <-prolog > void_test = 1; /* VOID FUNC */ > 100006a0: 00 00 00 60 nop <- location of break void_func > 100006a4: 58 81 22 39 addi r9,r2,-32424 > 100006a8: 01 00 40 39 li r10,1 > .... > > The test fails on PowerPC because the reverse execution never hits the > breakpoint at *void_func because the function is called using the local > entry point. Thus gdb returns to the caller after it reaches the local > entry point at address 10000694. It does not continue executing back > to the global entry point. The global entry point is only used in > special cases when the Table of Contents (TOC) pointer is not already > setup in r2. > > The question is how to fix the test in general? > > 1) Changing the breakpoint on *void_func to void_func will cause both > breakpoints to be the same regardless if there is a prolog. That > change would seem to invalidate the point of the test? > > 2) Disable the test for architectures where the assumption breakpoint > on foo and breakpoint on *foo is the same except for a prolog. The > downside is we are missing testing of some gdb functionality. Is there any way you can guarantee that the function will be called through the global entry point? Not just because this is the obvious solution, but because this would increase test coverage in GDB, seeing how reverse behaves on both possible entry points. Another possibility would be to change the underlying GDB mechanism, and make `break *foo` place the breakpoint at the local entry point, since it seems to pass by the local entry point regardless of where it actually enters. From what I understand about reverse debugging, GDB already has to do something similar to reverse-next over functions, so it should be a doable solution. A third possibility is trying to get the local entry point through disassembling the code and using `break *0xdeadbeef` instead. This would be the least intrusive solution, but I know nothing about different function entrypoints, so it might be too much work to be worth it. > > Is there another way to fix this test to run correctly on PowerPC? > > > The test gdb.reverse/next-reverse-bkpt-over-sr.exp also fails because > it does a break on *callee. Specifically, > > set lineno [gdb_get_line_number "STEP INTO THIS CALL"] > gdb_test "advance $lineno" ".*STEP INTO THIS CALL.*" "get past callee call" > > gdb_test "b \*callee" "" "set breakpoint at callee's entry" > > set bpnum [get_integer_valueof "\$bpnum" 0] > gdb_test "reverse-next" \ > "Breakpoint $bpnum, callee.*" \ > "reverse-next over call trips user breakpoint at function entry" > > gdb_test "up" \ > ".*NEXT OVER THIS CALL.*" \ > "stopped at the right callee call" > > In this case, it looks to me like changing the gdb_test to callee > instead of *callee doesn't break the point of the test. Making the > change on PowerPC fixes the test. > > Does anyone see any issues with changing the breakpoint from *callee to > calle for this test? I think it does invalidate the test, because GDB will place a step-resume breakpoint at *callee, and the test wants specifically to look at a user breakpoint at the same instruction. Cheers, Bruno > > Thanks for the input and help fixing these tests on PowerPC. > > Carl Love > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Questions on how best to fix two gdb tests gdb.reverse/finish-reverse-bkpt.exp and gdb.reverse/next-reverse-bkpt-over-sr.exp 2022-09-22 18:23 Questions on how best to fix two gdb tests gdb.reverse/finish-reverse-bkpt.exp and gdb.reverse/next-reverse-bkpt-over-sr.exp Carl Love 2022-09-23 9:13 ` Bruno Larsen @ 2022-09-23 10:48 ` Luis Machado 2022-09-23 10:56 ` Luis Machado 2022-09-26 14:36 ` Ulrich Weigand 1 sibling, 2 replies; 7+ messages in thread From: Luis Machado @ 2022-09-23 10:48 UTC (permalink / raw) To: Carl Love, gdb-patches; +Cc: Ulrich Weigand, Pedro Alves, Pedro Alves Hi Carl, gdbarch has a hook to adjust the breakpoint address (gdbarch_adjust_breakpoint_address). Can this be used to bend commands like "b *func" so they behave the same as other architectures? Alternatively, you may need to conditionally (for powerpc) walk through instructions and locate the correct address for the breakpoint. On 9/22/22 19:23, Carl Love via Gdb-patches wrote: > GDB community: > > There are two gdb tests gdb.reverse/finish-reverse-bkpt.exp and > gdb.reverse/next-reverse-bkpt-over-sr.exp which fail for similar > reasons on PowerPC. It appears to me that the issues are with the > tests and not with gdb itself. Both tests set breakpoints on *func > where func is a function in the source file. This is the fundamental > issue with both tests. > > The test gdb.reverse/finish-reverse-bkpt.exp has the comment: > > gdb_test "tbreak void_func" \ > "Temporary breakpoint $decimal at .*$srcfile, line $breakloc\." \ > "set breakpoint on void_func" > gdb_continue_to_breakpoint "void_func" ".*$srcfile:$breakloc.*" > > # We stop at the brekapoint on void_func, but breakpoint on > # *void_func will be set at the same place if function void_func doesn't > # have prologue. One step forward to avoid this. > gdb_test "si" > > gdb_test "break \*void_func" \ > "Breakpoint $decimal at .*" \ > "set breakpoint at void_func's entry" > > The comment about break point on void_func and breakpoint on *void_func > being the same if there is no prolong is not true for all > architectures. Specifically PowerPC uses local and global entry > points. The statement "break *foo" sets the breakpoint at the address > of the first instruction in the function where as "break foo" sets the > breakpoint at the beginning of the function, i.e. after the prolog > following the local entry point. Specifically for this test the > PowerPC assembly code is as follows: > > void void_func () > { > 1000068c: 02 10 40 3c lis r2,4098 <-global entry point, > location of break *void_func > 10000690: 00 7f 42 38 addi r2,r2,32512 > 10000694: f8 ff e1 fb std r31,-8(r1) <-local entry point > 10000698: d1 ff 21 f8 stdu r1,-48(r1) <-prolog > 1000069c: 78 0b 3f 7c mr r31,r1 <-prolog > void_test = 1; /* VOID FUNC */ > 100006a0: 00 00 00 60 nop <- location of break void_func > 100006a4: 58 81 22 39 addi r9,r2,-32424 > 100006a8: 01 00 40 39 li r10,1 > .... > > The test fails on PowerPC because the reverse execution never hits the > breakpoint at *void_func because the function is called using the local > entry point. Thus gdb returns to the caller after it reaches the local > entry point at address 10000694. It does not continue executing back > to the global entry point. The global entry point is only used in > special cases when the Table of Contents (TOC) pointer is not already > setup in r2. > > The question is how to fix the test in general? > > 1) Changing the breakpoint on *void_func to void_func will cause both > breakpoints to be the same regardless if there is a prolog. That > change would seem to invalidate the point of the test? > > 2) Disable the test for architectures where the assumption breakpoint > on foo and breakpoint on *foo is the same except for a prolog. The > downside is we are missing testing of some gdb functionality. > > Is there another way to fix this test to run correctly on PowerPC? > > > The test gdb.reverse/next-reverse-bkpt-over-sr.exp also fails because > it does a break on *callee. Specifically, > > set lineno [gdb_get_line_number "STEP INTO THIS CALL"] > gdb_test "advance $lineno" ".*STEP INTO THIS CALL.*" "get past callee call" > > gdb_test "b \*callee" "" "set breakpoint at callee's entry" > > set bpnum [get_integer_valueof "\$bpnum" 0] > gdb_test "reverse-next" \ > "Breakpoint $bpnum, callee.*" \ > "reverse-next over call trips user breakpoint at function entry" > > gdb_test "up" \ > ".*NEXT OVER THIS CALL.*" \ > "stopped at the right callee call" > > In this case, it looks to me like changing the gdb_test to callee > instead of *callee doesn't break the point of the test. Making the > change on PowerPC fixes the test. > > Does anyone see any issues with changing the breakpoint from *callee to > calle for this test? > > Thanks for the input and help fixing these tests on PowerPC. > > Carl Love > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Questions on how best to fix two gdb tests gdb.reverse/finish-reverse-bkpt.exp and gdb.reverse/next-reverse-bkpt-over-sr.exp 2022-09-23 10:48 ` Luis Machado @ 2022-09-23 10:56 ` Luis Machado 2022-09-26 14:36 ` Ulrich Weigand 1 sibling, 0 replies; 7+ messages in thread From: Luis Machado @ 2022-09-23 10:56 UTC (permalink / raw) To: Carl Love, gdb-patches; +Cc: Ulrich Weigand, Pedro Alves, Pedro Alves On 9/23/22 11:48, Luis Machado via Gdb-patches wrote: > Hi Carl, > > gdbarch has a hook to adjust the breakpoint address (gdbarch_adjust_breakpoint_address). Can this be used to bend commands > like "b *func" so they behave the same as other architectures? > > Alternatively, you may need to conditionally (for powerpc) walk through instructions and locate > the correct address for the breakpoint. Also, "break *func" is a fairly common command for users to issue when they want to stop exactly at the address of func. Even though this is not technically always true, I think it is still pretty intuitive to expect that it will work. Should GDB issue a warning of some kind so users are aware this doesn't work for power? It would also help you track down testcases that expect this to work, and maybe some others that just happen to work but may break in the future. > > On 9/22/22 19:23, Carl Love via Gdb-patches wrote: >> GDB community: >> >> There are two gdb tests gdb.reverse/finish-reverse-bkpt.exp and >> gdb.reverse/next-reverse-bkpt-over-sr.exp which fail for similar >> reasons on PowerPC. It appears to me that the issues are with the >> tests and not with gdb itself. Both tests set breakpoints on *func >> where func is a function in the source file. This is the fundamental >> issue with both tests. >> >> The test gdb.reverse/finish-reverse-bkpt.exp has the comment: >> >> gdb_test "tbreak void_func" \ >> "Temporary breakpoint $decimal at .*$srcfile, line $breakloc\." \ >> "set breakpoint on void_func" >> gdb_continue_to_breakpoint "void_func" ".*$srcfile:$breakloc.*" >> >> # We stop at the brekapoint on void_func, but breakpoint on >> # *void_func will be set at the same place if function void_func doesn't >> # have prologue. One step forward to avoid this. >> gdb_test "si" >> >> gdb_test "break \*void_func" \ >> "Breakpoint $decimal at .*" \ >> "set breakpoint at void_func's entry" >> >> The comment about break point on void_func and breakpoint on *void_func >> being the same if there is no prolong is not true for all >> architectures. Specifically PowerPC uses local and global entry >> points. The statement "break *foo" sets the breakpoint at the address >> of the first instruction in the function where as "break foo" sets the >> breakpoint at the beginning of the function, i.e. after the prolog >> following the local entry point. Specifically for this test the >> PowerPC assembly code is as follows: >> >> void void_func () >> { >> 1000068c: 02 10 40 3c lis r2,4098 <-global entry point, >> location of break *void_func >> 10000690: 00 7f 42 38 addi r2,r2,32512 >> 10000694: f8 ff e1 fb std r31,-8(r1) <-local entry point >> 10000698: d1 ff 21 f8 stdu r1,-48(r1) <-prolog >> 1000069c: 78 0b 3f 7c mr r31,r1 <-prolog >> void_test = 1; /* VOID FUNC */ >> 100006a0: 00 00 00 60 nop <- location of break void_func >> 100006a4: 58 81 22 39 addi r9,r2,-32424 >> 100006a8: 01 00 40 39 li r10,1 >> .... >> >> The test fails on PowerPC because the reverse execution never hits the >> breakpoint at *void_func because the function is called using the local >> entry point. Thus gdb returns to the caller after it reaches the local >> entry point at address 10000694. It does not continue executing back >> to the global entry point. The global entry point is only used in >> special cases when the Table of Contents (TOC) pointer is not already >> setup in r2. >> >> The question is how to fix the test in general? >> >> 1) Changing the breakpoint on *void_func to void_func will cause both >> breakpoints to be the same regardless if there is a prolog. That >> change would seem to invalidate the point of the test? >> >> 2) Disable the test for architectures where the assumption breakpoint >> on foo and breakpoint on *foo is the same except for a prolog. The >> downside is we are missing testing of some gdb functionality. >> >> Is there another way to fix this test to run correctly on PowerPC? >> >> >> The test gdb.reverse/next-reverse-bkpt-over-sr.exp also fails because >> it does a break on *callee. Specifically, >> >> set lineno [gdb_get_line_number "STEP INTO THIS CALL"] >> gdb_test "advance $lineno" ".*STEP INTO THIS CALL.*" "get past callee call" >> >> gdb_test "b \*callee" "" "set breakpoint at callee's entry" >> >> set bpnum [get_integer_valueof "\$bpnum" 0] >> gdb_test "reverse-next" \ >> "Breakpoint $bpnum, callee.*" \ >> "reverse-next over call trips user breakpoint at function entry" >> >> gdb_test "up" \ >> ".*NEXT OVER THIS CALL.*" \ >> "stopped at the right callee call" >> >> In this case, it looks to me like changing the gdb_test to callee >> instead of *callee doesn't break the point of the test. Making the >> change on PowerPC fixes the test. >> >> Does anyone see any issues with changing the breakpoint from *callee to >> calle for this test? >> >> Thanks for the input and help fixing these tests on PowerPC. >> >> Carl Love >> > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Questions on how best to fix two gdb tests gdb.reverse/finish-reverse-bkpt.exp and gdb.reverse/next-reverse-bkpt-over-sr.exp 2022-09-23 10:48 ` Luis Machado 2022-09-23 10:56 ` Luis Machado @ 2022-09-26 14:36 ` Ulrich Weigand 2022-09-26 15:30 ` Carl Love 1 sibling, 1 reply; 7+ messages in thread From: Ulrich Weigand @ 2022-09-26 14:36 UTC (permalink / raw) To: gdb-patches, luis.machado, cel; +Cc: palves, pedro Luis Machado <luis.machado@arm.com> wrote: >gdbarch has a hook to adjust the breakpoint address >(gdbarch_adjust_breakpoint_address). Can this be used to bend commands >like "b *func" so they behave the same as other architectures? I don't think this works. The problem is that "b *func" is a weird hack that combines two aspects: use of "func" as a value that at this point is just a plain symbol table lookup; and use of "*" to set a breakpoint at an explicitly specified absolute address. Neither of these aspects is something we want to change on its own. We do want a plain symbol, if used as a value, to return the address that is in the symbol table. Everything else would just be confusing, and could also break things if "if ptr == func" where "ptr" is a function pointer variable. On the other hand, when using "b *<addr>" with some hard-coded address, we actually want the breakpoint to be exactly there and nowhere else; that is usually used by someone familiar with the platform who want to set the breakpoint exactly there. (Or, possibly, by clicking on "set breakpoint" in a GUI switched to the assembly view.) Automatically moving this to a different address would be weird, when the whole point of "*" is that it *isn't* trying to be clever, unlike say "b func". It is an unfortunate fact that these two properties, which are each desired on their own, combine to yield an undesirable effect when used as "b *func" on Power. But I think the root cause of this is that "b *func" is used here in a way that is not justified by the actual specification of those features. Actually, I'm not seeing much use of this particular construct at all, outside of the GDB test suite. And here, it is used in the idiosyncratic manner of "do a 'b func' but just without skipping the prolog", usually because of some GDB test suite internal reason why we want to avoid prolog skipping just here. It seems to me that the real fix would be some new syntax that makes this goal explicit, maybe along the lines of b -entrypoint func (It would still be preferable to me to investigate use of this construct throughout the test suite to see if it is *really* necessary or if the tests can simply be rewritten in a way that they don't need the "skip prolog" feature anyway ...) Bye, Ulrich ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Questions on how best to fix two gdb tests gdb.reverse/finish-reverse-bkpt.exp and gdb.reverse/next-reverse-bkpt-over-sr.exp 2022-09-26 14:36 ` Ulrich Weigand @ 2022-09-26 15:30 ` Carl Love 2022-09-26 16:08 ` Bruno Larsen 0 siblings, 1 reply; 7+ messages in thread From: Carl Love @ 2022-09-26 15:30 UTC (permalink / raw) To: Ulrich Weigand, gdb-patches, luis.machado Ulrich, Luis: On Mon, 2022-09-26 at 14:36 +0000, Ulrich Weigand wrote: > Luis Machado <luis.machado@arm.com> wrote: > > > gdbarch has a hook to adjust the breakpoint address > > (gdbarch_adjust_breakpoint_address). Can this be used to bend > > commands > > like "b *func" so they behave the same as other architectures? > > I don't think this works. The problem is that "b *func" is a weird > hack that combines two aspects: use of "func" as a value that at this > point is just a plain symbol table lookup; and use of "*" to set a > breakpoint at an explicitly specified absolute address. > > Neither of these aspects is something we want to change on its own. > We do want a plain symbol, if used as a value, to return the > address that is in the symbol table. Everything else would just > be confusing, and could also break things if "if ptr == func" > where "ptr" is a function pointer variable. > > On the other hand, when using "b *<addr>" with some hard-coded > address, we actually want the breakpoint to be exactly there > and nowhere else; that is usually used by someone familiar with > the platform who want to set the breakpoint exactly there. (Or, > possibly, by clicking on "set breakpoint" in a GUI switched to > the assembly view.) Automatically moving this to a different > address would be weird, when the whole point of "*" is that it > *isn't* trying to be clever, unlike say "b func". > > It is an unfortunate fact that these two properties, which are > each desired on their own, combine to yield an undesirable > effect when used as "b *func" on Power. But I think the root > cause of this is that "b *func" is used here in a way that is > not justified by the actual specification of those features. > > Actually, I'm not seeing much use of this particular construct > at all, outside of the GDB test suite. And here, it is used > in the idiosyncratic manner of "do a 'b func' but just without > skipping the prolog", usually because of some GDB test suite > internal reason why we want to avoid prolog skipping just here. > > It seems to me that the real fix would be some new syntax that > makes this goal explicit, maybe along the lines of > b -entrypoint func > > (It would still be preferable to me to investigate use of this > construct throughout the test suite to see if it is *really* > necessary or if the tests can simply be rewritten in a way > that they don't need the "skip prolog" feature anyway ...) I looked at the suggestion from Luis. In the end, I really didn't think changing gdb to make the test work is really the best idea. The issue is that there are cases, as Ulrich said, where someone who knows the details may actually want to set the breakpoint on the first instruction. If I change gdb, to fix the test by "adjusting" the desired breakpoint then the user is no longer able to stop where they want to. I am not sure why the original test was concerned about the prolog. The original author doesn't seem to be around anymore. I will think about how to change the first test some more. I don't see any issues with changing the second test to just break on the function callee rather than *callee. I will submit a patch to change the second test. Carl ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Questions on how best to fix two gdb tests gdb.reverse/finish-reverse-bkpt.exp and gdb.reverse/next-reverse-bkpt-over-sr.exp 2022-09-26 15:30 ` Carl Love @ 2022-09-26 16:08 ` Bruno Larsen 0 siblings, 0 replies; 7+ messages in thread From: Bruno Larsen @ 2022-09-26 16:08 UTC (permalink / raw) To: Carl Love, Ulrich Weigand, gdb-patches, luis.machado On 26/09/2022 17:30, Carl Love via Gdb-patches wrote: > Ulrich, Luis: > > On Mon, 2022-09-26 at 14:36 +0000, Ulrich Weigand wrote: >> Luis Machado <luis.machado@arm.com> wrote: >> >>> gdbarch has a hook to adjust the breakpoint address >>> (gdbarch_adjust_breakpoint_address). Can this be used to bend >>> commands >>> like "b *func" so they behave the same as other architectures? >> I don't think this works. The problem is that "b *func" is a weird >> hack that combines two aspects: use of "func" as a value that at this >> point is just a plain symbol table lookup; and use of "*" to set a >> breakpoint at an explicitly specified absolute address. >> >> Neither of these aspects is something we want to change on its own. >> We do want a plain symbol, if used as a value, to return the >> address that is in the symbol table. Everything else would just >> be confusing, and could also break things if "if ptr == func" >> where "ptr" is a function pointer variable. >> >> On the other hand, when using "b *<addr>" with some hard-coded >> address, we actually want the breakpoint to be exactly there >> and nowhere else; that is usually used by someone familiar with >> the platform who want to set the breakpoint exactly there. (Or, >> possibly, by clicking on "set breakpoint" in a GUI switched to >> the assembly view.) Automatically moving this to a different >> address would be weird, when the whole point of "*" is that it >> *isn't* trying to be clever, unlike say "b func". >> >> It is an unfortunate fact that these two properties, which are >> each desired on their own, combine to yield an undesirable >> effect when used as "b *func" on Power. But I think the root >> cause of this is that "b *func" is used here in a way that is >> not justified by the actual specification of those features. >> >> Actually, I'm not seeing much use of this particular construct >> at all, outside of the GDB test suite. And here, it is used >> in the idiosyncratic manner of "do a 'b func' but just without >> skipping the prolog", usually because of some GDB test suite >> internal reason why we want to avoid prolog skipping just here. >> >> It seems to me that the real fix would be some new syntax that >> makes this goal explicit, maybe along the lines of >> b -entrypoint func >> >> (It would still be preferable to me to investigate use of this >> construct throughout the test suite to see if it is *really* >> necessary or if the tests can simply be rewritten in a way >> that they don't need the "skip prolog" feature anyway ...) > I looked at the suggestion from Luis. In the end, I really didn't > think changing gdb to make the test work is really the best idea. The > issue is that there are cases, as Ulrich said, where someone who knows > the details may actually want to set the breakpoint on the first > instruction. If I change gdb, to fix the test by "adjusting" the > desired breakpoint then the user is no longer able to stop where they > want to. > > I am not sure why the original test was concerned about the prolog. > The original author doesn't seem to be around anymore. I will think > about how to change the first test some more. From what I could see in the comments of the test, the problem was that reverse-finishing out of the function would ignore breakpoints that were set before the prologue. In case you aren't familiar with how GDB does a reverse-finish (and sorry if you are), it decides what is the first instruction executed in the current frame, places a breakpoint there, and reverse-continues until that breakpoint is hit. GDB then removes that breakpoint and does a reverse-stepi to leave the function call. If there was already a user breakpoint at that instruction, GDB should _not_ do the reverse-stepi. For this test, it seems imperative that the breakpoint is placed before the prologue, since it is where GDB would place the step-resume-breakpoint that reverse-finish uses. > > I don't see any issues with changing the second test to just break on > the function callee rather than *callee. I will submit a patch to > change the second test. Same goes for the second test. It explicitly states that GDB was removing the user-placed breakpoint if it was placed at the exact same instruction as step-resume-breakpoint would be hit, so moving the breakpoint to after the prologue would render the test useless, as the bug conditions wouldn't be met anymore. What you probably want to do in both cases is find a way to get the addresses of the functions and set a breakpoint there as "b *(address)" instead, though I'm not sure how I'd suggest you do it. Cheers, Bruno > > Carl > ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-09-26 16:08 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-09-22 18:23 Questions on how best to fix two gdb tests gdb.reverse/finish-reverse-bkpt.exp and gdb.reverse/next-reverse-bkpt-over-sr.exp Carl Love 2022-09-23 9:13 ` Bruno Larsen 2022-09-23 10:48 ` Luis Machado 2022-09-23 10:56 ` Luis Machado 2022-09-26 14:36 ` Ulrich Weigand 2022-09-26 15:30 ` Carl Love 2022-09-26 16:08 ` Bruno Larsen
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).