* Indicating function exit points in debug data @ 2019-03-19 20:38 Justin Paston-Cooper 2019-03-19 21:29 ` Florian Weimer 2019-03-20 8:31 ` Richard Biener 0 siblings, 2 replies; 14+ messages in thread From: Justin Paston-Cooper @ 2019-03-19 20:38 UTC (permalink / raw) To: gcc Hello, In my message https://sourceware.org/ml/gdb/2019-03/msg00042.html to the gdb mailing list, I asked whether it would be possible to implement a command which breaks at all exit points of the current stack frame. This would be very useful for evaluating a function's final state before it returns its result, independent of where in its definition it returns from. Tom Tromey suggested in that thread that this would be quite easy on gdb's side if gcc indicates exit locations in the DWARF data, for instance in the C case, it would indicate the locations of return statements. On a related note, he mentions that the "finish" command does not work for inlined functions because the compiler does not emit the required information. It would be nice if this new break on exit command worked both for inlined functions, and also the case of breaking after tail-recursions exit. With a single stone, the "finish" bird above is also killed. Would it be feasible to implement such a feature in gcc? If I'm not the first person to ask for this, are there any architectural or practical reasons as to why it might not be possible to implement? As it stands, I don't have the level of familiarity with gcc to come to you with a patch, but with guidance I would certainly be interested in working on the C/C++ case if that would be useful. Thanks, Justin ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Indicating function exit points in debug data 2019-03-19 20:38 Indicating function exit points in debug data Justin Paston-Cooper @ 2019-03-19 21:29 ` Florian Weimer 2019-03-19 21:41 ` Justin Paston-Cooper 2019-03-20 8:31 ` Richard Biener 1 sibling, 1 reply; 14+ messages in thread From: Florian Weimer @ 2019-03-19 21:29 UTC (permalink / raw) To: Justin Paston-Cooper; +Cc: gcc * Justin Paston-Cooper: > Tom Tromey suggested in that thread that this would be quite easy on > gdb's side if gcc indicates exit locations in the DWARF data, for > instance in the C case, it would indicate the locations of return > statements. On a related note, he mentions that the "finish" command > does not work for inlined functions because the compiler does not emit > the required information. What about calls to noreturn functions? I assume they would need breakpoints as well. It could be tricky if those are only called indirectly, I assume. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Indicating function exit points in debug data 2019-03-19 21:29 ` Florian Weimer @ 2019-03-19 21:41 ` Justin Paston-Cooper 2019-03-19 21:52 ` Florian Weimer 0 siblings, 1 reply; 14+ messages in thread From: Justin Paston-Cooper @ 2019-03-19 21:41 UTC (permalink / raw) To: Florian Weimer; +Cc: gcc On Tue, 19 Mar 2019 at 21:29, Florian Weimer <fw@deneb.enyo.de> wrote: > > * Justin Paston-Cooper: > > > Tom Tromey suggested in that thread that this would be quite easy on > > gdb's side if gcc indicates exit locations in the DWARF data, for > > instance in the C case, it would indicate the locations of return > > statements. On a related note, he mentions that the "finish" command > > does not work for inlined functions because the compiler does not emit > > the required information. > > What about calls to noreturn functions? I assume they would need > breakpoints as well. It could be tricky if those are only called > indirectly, I assume. Couldn't the brace following the final line of an inlined noreturn function be viewed as its exit point and be indicated in the DWARF information accordingly? Is the problem that each entry in the line number table has to point to a specific statement? Could you explain what you mean with "indirectly"? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Indicating function exit points in debug data 2019-03-19 21:41 ` Justin Paston-Cooper @ 2019-03-19 21:52 ` Florian Weimer 2019-03-19 22:20 ` Justin Paston-Cooper 0 siblings, 1 reply; 14+ messages in thread From: Florian Weimer @ 2019-03-19 21:52 UTC (permalink / raw) To: Justin Paston-Cooper; +Cc: gcc * Justin Paston-Cooper: > On Tue, 19 Mar 2019 at 21:29, Florian Weimer <fw@deneb.enyo.de> wrote: >> >> * Justin Paston-Cooper: >> >> > Tom Tromey suggested in that thread that this would be quite easy on >> > gdb's side if gcc indicates exit locations in the DWARF data, for >> > instance in the C case, it would indicate the locations of return >> > statements. On a related note, he mentions that the "finish" command >> > does not work for inlined functions because the compiler does not emit >> > the required information. >> >> What about calls to noreturn functions? I assume they would need >> breakpoints as well. It could be tricky if those are only called >> indirectly, I assume. > > Couldn't the brace following the final line of an inlined noreturn > function be viewed as its exit point and be indicated in the DWARF > information accordingly? That breakpoint would never be reached. > Is the problem that each entry in the line > number table has to point to a specific statement? Could you explain > what you mean with "indirectly"? In C++, a function might return to the caller by calling *another* function which throws an exception. Similarly, in C, a function could call a function that in turn calls longjmp. Or more prosaically, a called function might call the exit function. I'm just wondering if such abnormal exits should be covered as well, and calling a noreturn function could be a reasonable indicator. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Indicating function exit points in debug data 2019-03-19 21:52 ` Florian Weimer @ 2019-03-19 22:20 ` Justin Paston-Cooper 2019-03-19 22:40 ` Florian Weimer 0 siblings, 1 reply; 14+ messages in thread From: Justin Paston-Cooper @ 2019-03-19 22:20 UTC (permalink / raw) To: Florian Weimer; +Cc: gcc On Tue, 19 Mar 2019 at 21:52, Florian Weimer <fw@deneb.enyo.de> wrote: > > * Justin Paston-Cooper: > > > On Tue, 19 Mar 2019 at 21:29, Florian Weimer <fw@deneb.enyo.de> wrote: > >> > >> * Justin Paston-Cooper: > >> > >> > Tom Tromey suggested in that thread that this would be quite easy on > >> > gdb's side if gcc indicates exit locations in the DWARF data, for > >> > instance in the C case, it would indicate the locations of return > >> > statements. On a related note, he mentions that the "finish" command > >> > does not work for inlined functions because the compiler does not emit > >> > the required information. > >> > >> What about calls to noreturn functions? I assume they would need > >> breakpoints as well. It could be tricky if those are only called > >> indirectly, I assume. > > > > Couldn't the brace following the final line of an inlined noreturn > > function be viewed as its exit point and be indicated in the DWARF > > information accordingly? > > That breakpoint would never be reached. Then if the break on exit command would break on return statements of functions which return, then it could break on the final statement of a noreturn? > > > Is the problem that each entry in the line > > number table has to point to a specific statement? Could you explain > > what you mean with "indirectly"? > > In C++, a function might return to the caller by calling *another* > function which throws an exception. > > Similarly, in C, a function could call a function that in turn calls > longjmp. > > Or more prosaically, a called function might call the exit function. > > I'm just wondering if such abnormal exits should be covered as well, > and calling a noreturn function could be a reasonable indicator. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Indicating function exit points in debug data 2019-03-19 22:20 ` Justin Paston-Cooper @ 2019-03-19 22:40 ` Florian Weimer 2019-03-19 22:52 ` Justin Paston-Cooper 0 siblings, 1 reply; 14+ messages in thread From: Florian Weimer @ 2019-03-19 22:40 UTC (permalink / raw) To: Justin Paston-Cooper; +Cc: gcc * Justin Paston-Cooper: > On Tue, 19 Mar 2019 at 21:52, Florian Weimer <fw@deneb.enyo.de> wrote: >> >> * Justin Paston-Cooper: >> >> > On Tue, 19 Mar 2019 at 21:29, Florian Weimer <fw@deneb.enyo.de> wrote: >> >> >> >> * Justin Paston-Cooper: >> >> >> >> > Tom Tromey suggested in that thread that this would be quite easy on >> >> > gdb's side if gcc indicates exit locations in the DWARF data, for >> >> > instance in the C case, it would indicate the locations of return >> >> > statements. On a related note, he mentions that the "finish" command >> >> > does not work for inlined functions because the compiler does not emit >> >> > the required information. >> >> >> >> What about calls to noreturn functions? I assume they would need >> >> breakpoints as well. It could be tricky if those are only called >> >> indirectly, I assume. >> > >> > Couldn't the brace following the final line of an inlined noreturn >> > function be viewed as its exit point and be indicated in the DWARF >> > information accordingly? >> >> That breakpoint would never be reached. > > Then if the break on exit command would break on return statements of > functions which return, then it could break on the final statement of > a noreturn? There's no final statement in a noreturn function because it will never return. It either has an endless loop, or it calls another noreturn function (which is at a certain point opaque to the compiler) which never returns. Sorry, I have a fealing we are talking past each other. With “noreturn function”, I mean a function that is annotated with the noreturn attribute: <https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-noreturn-function-attribute> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Indicating function exit points in debug data 2019-03-19 22:40 ` Florian Weimer @ 2019-03-19 22:52 ` Justin Paston-Cooper 0 siblings, 0 replies; 14+ messages in thread From: Justin Paston-Cooper @ 2019-03-19 22:52 UTC (permalink / raw) To: Florian Weimer; +Cc: gcc On Tue, 19 Mar 2019 at 22:40, Florian Weimer <fw@deneb.enyo.de> wrote: > * Justin Paston-Cooper: > > > On Tue, 19 Mar 2019 at 21:52, Florian Weimer <fw@deneb.enyo.de> wrote: > >> > >> * Justin Paston-Cooper: > >> > >> > On Tue, 19 Mar 2019 at 21:29, Florian Weimer <fw@deneb.enyo.de> > wrote: > >> >> > >> >> * Justin Paston-Cooper: > >> >> > >> >> > Tom Tromey suggested in that thread that this would be quite easy > on > >> >> > gdb's side if gcc indicates exit locations in the DWARF data, for > >> >> > instance in the C case, it would indicate the locations of return > >> >> > statements. On a related note, he mentions that the "finish" > command > >> >> > does not work for inlined functions because the compiler does not > emit > >> >> > the required information. > >> >> > >> >> What about calls to noreturn functions? I assume they would need > >> >> breakpoints as well. It could be tricky if those are only called > >> >> indirectly, I assume. > >> > > >> > Couldn't the brace following the final line of an inlined noreturn > >> > function be viewed as its exit point and be indicated in the DWARF > >> > information accordingly? > >> > >> That breakpoint would never be reached. > > > > Then if the break on exit command would break on return statements of > > functions which return, then it could break on the final statement of > > a noreturn? > > There's no final statement in a noreturn function because it will > never return. It either has an endless loop, or it calls another > noreturn function (which is at a certain point opaque to the compiler) > which never returns. > > Sorry, I have a fealing we are talking past each other. With > “noreturn function”, I mean a function that is annotated with the > noreturn attribute: > > < > https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-noreturn-function-attribute > > > Sorry about that, and thanks for the link. I jumped to conclusions with regards to the meaning of noreturn. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Indicating function exit points in debug data 2019-03-19 20:38 Indicating function exit points in debug data Justin Paston-Cooper 2019-03-19 21:29 ` Florian Weimer @ 2019-03-20 8:31 ` Richard Biener 2019-03-20 10:13 ` Justin Paston-Cooper 1 sibling, 1 reply; 14+ messages in thread From: Richard Biener @ 2019-03-20 8:31 UTC (permalink / raw) To: Justin Paston-Cooper; +Cc: GCC Development On Tue, Mar 19, 2019 at 9:38 PM Justin Paston-Cooper <paston.cooper@gmail.com> wrote: > > Hello, > > In my message https://sourceware.org/ml/gdb/2019-03/msg00042.html to > the gdb mailing list, I asked whether it would be possible to > implement a command which breaks at all exit points of the current > stack frame. This would be very useful for evaluating a function's > final state before it returns its result, independent of where in its > definition it returns from. > > Tom Tromey suggested in that thread that this would be quite easy on > gdb's side if gcc indicates exit locations in the DWARF data, for Did he indicate _how_ to represent this in DWARF? I suppose the breakpoint should happen before the local frame is teared down. > instance in the C case, it would indicate the locations of return > statements. On a related note, he mentions that the "finish" command > does not work for inlined functions because the compiler does not emit > the required information. While "finish" wants a location at the caller side, after the inlined frame is teared down. So they are somewhat distinct. Can you open two enhancement requests in buzilla? Thanks, Richard. > It would be nice if this new break on exit command worked both for > inlined functions, and also the case of breaking after tail-recursions > exit. With a single stone, the "finish" bird above is also killed. > Would it be feasible to implement such a feature in gcc? If I'm not > the first person to ask for this, are there any architectural or > practical reasons as to why it might not be possible to implement? As > it stands, I don't have the level of familiarity with gcc to come to > you with a patch, but with guidance I would certainly be interested in > working on the C/C++ case if that would be useful. > > Thanks, > > Justin ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Indicating function exit points in debug data 2019-03-20 8:31 ` Richard Biener @ 2019-03-20 10:13 ` Justin Paston-Cooper 2019-03-20 17:36 ` Segher Boessenkool 0 siblings, 1 reply; 14+ messages in thread From: Justin Paston-Cooper @ 2019-03-20 10:13 UTC (permalink / raw) To: Richard Biener; +Cc: GCC Development On Wed, 20 Mar 2019 at 08:31, Richard Biener <richard.guenther@gmail.com> wrote: > > On Tue, Mar 19, 2019 at 9:38 PM Justin Paston-Cooper > <paston.cooper@gmail.com> wrote: > > > > Hello, > > > > In my message https://sourceware.org/ml/gdb/2019-03/msg00042.html to > > the gdb mailing list, I asked whether it would be possible to > > implement a command which breaks at all exit points of the current > > stack frame. This would be very useful for evaluating a function's > > final state before it returns its result, independent of where in its > > definition it returns from. > > > > Tom Tromey suggested in that thread that this would be quite easy on > > gdb's side if gcc indicates exit locations in the DWARF data, for > > Did he indicate _how_ to represent this in DWARF? I suppose the breakpoint > should happen before the local frame is teared down. Tom didn't suggest any specific implementation. Simon Marchi in the same thread said, "I suppose that the list of all function exit points (regardless of whether it is a jump or real return) is an information that the compiler could theoretically produce and encode in the DWARF information?". I had a look at the DWARF5 specification. Section 6.2.2 outlines the registers of the state machine which deals with line number information. One of those registers is named "epilogue_begin". Its definition is: ----- A boolean indicating that the current address is one (of possibly many) where execution should be suspended for a breakpoint just prior to the exit of a function. ----- Section 6.2.5.2 outlines the line number information state machine's opcodes. One of them is "DW_LNS_set_epilogue_begin". Its definition is: ----- The DW_LNS_set_epilogue_begin opcode takes no operands. It sets the epilogue_begin register to “true”. When a breakpoint is set on the exit of a function or execution steps over the last executable statement of a function, it is generally desirable to suspend execution after completion of the last statement but prior to tearing down the frame (so that local variables can still be examined). Debuggers generally cannot properly determine where this point is. This command allows a compiler to communicate the location(s) to use. Note that the function to which the epilogue end applies cannot be directly determined from the line number information alone; it must be determined in combination with the subroutine information entries of the compilation (including inlined subroutines). In the case of a trivial function, both prologue end and epilogue begin may occur at the same address. ----- Shouldn't this be sufficient for gdb to work backwards and determine the _beginning_ of any exit statement of a function? I had a look into gcc's involvement with "epilogue_begin". The pass called "pass_thread_prologue_and_epilogue" transitively calls a function defined in function.c called "make_epilogue_seq", which as far as I understand emits an "epilogue_begin" note. I'm not sure how this pass ties in with each frontend. Does a frontend need to support this pass explicitly? If so, is it just not supported by a lot of frontends? Given that no one on the gdb thread mentioned this pass, is there another problem which I am not aware of? > > > instance in the C case, it would indicate the locations of return > > statements. On a related note, he mentions that the "finish" command > > does not work for inlined functions because the compiler does not emit > > the required information. > > While "finish" wants a location at the caller side, after the inlined frame is > teared down. So they are somewhat distinct. Obviously I'm not familiar with gcc/gdb internals, but superficially my idea was that if 'finish' has access to the information on the exit points of an inlined function, then it can keep track of which register/location the "return" value ends up in. > > Can you open two enhancement requests in buzilla? Will do. > > Thanks, > Richard. > > > It would be nice if this new break on exit command worked both for > > inlined functions, and also the case of breaking after tail-recursions > > exit. With a single stone, the "finish" bird above is also killed. > > > Would it be feasible to implement such a feature in gcc? If I'm not > > the first person to ask for this, are there any architectural or > > practical reasons as to why it might not be possible to implement? As > > it stands, I don't have the level of familiarity with gcc to come to > > you with a patch, but with guidance I would certainly be interested in > > working on the C/C++ case if that would be useful. > > > > Thanks, > > > > Justin ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Indicating function exit points in debug data 2019-03-20 10:13 ` Justin Paston-Cooper @ 2019-03-20 17:36 ` Segher Boessenkool 2019-03-20 19:05 ` Tom Tromey 0 siblings, 1 reply; 14+ messages in thread From: Segher Boessenkool @ 2019-03-20 17:36 UTC (permalink / raw) To: Justin Paston-Cooper; +Cc: Richard Biener, GCC Development On Wed, Mar 20, 2019 at 10:13:23AM +0000, Justin Paston-Cooper wrote: > Section 6.2.5.2 outlines the line number information state machine's > opcodes. One of them is "DW_LNS_set_epilogue_begin". Its definition > is: > > ----- > The DW_LNS_set_epilogue_begin opcode takes no operands. It sets the > epilogue_begin register to âtrueâ. When a breakpoint is set on the > exit of a function or execution steps over the last executable > statement of a function, it is generally desirable to suspend > execution after completion of the last statement but prior to tearing > down the frame (so that local variables can still be examined). > Debuggers generally cannot properly determine where this point is. > This command allows a compiler to communicate the location(s) to use. > Note that the function to which the epilogue end applies cannot be > directly determined from the line number information alone; it must be > determined in combination with the subroutine information entries of > the compilation (including inlined subroutines). In the case of a > trivial function, both prologue end and epilogue begin may occur at > the same address. > ----- How should this work with shrink-wrapping? The whole point of that is you do not tear down the frame after all other code, etc. I don't see how we can do better than putting this DW_LNS_set_epilogue_begin right before the actual return -- and that is after all the tear down etc. > I had a look into > gcc's involvement with "epilogue_begin". The pass called > "pass_thread_prologue_and_epilogue" transitively calls a function > defined in function.c called "make_epilogue_seq", which as far as I > understand emits an "epilogue_begin" note. I'm not sure how this pass > ties in with each frontend. Does a frontend need to support this pass > explicitly? Nope. This pass is very late in the backend, after register allocation and everything. A frontend will just make functions "return", and that's all it has to do. Segher ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Indicating function exit points in debug data 2019-03-20 17:36 ` Segher Boessenkool @ 2019-03-20 19:05 ` Tom Tromey 2019-03-21 8:23 ` Richard Biener 0 siblings, 1 reply; 14+ messages in thread From: Tom Tromey @ 2019-03-20 19:05 UTC (permalink / raw) To: Segher Boessenkool; +Cc: Justin Paston-Cooper, Richard Biener, GCC Development >>>>> "Segher" == Segher Boessenkool <segher@kernel.crashing.org> writes: >> Section 6.2.5.2 outlines the line number information state machine's >> opcodes. One of them is "DW_LNS_set_epilogue_begin". Its definition >> is: Segher> How should this work with shrink-wrapping? The whole point of that is Segher> you do not tear down the frame after all other code, etc. I don't see Segher> how we can do better than putting this DW_LNS_set_epilogue_begin right Segher> before the actual return -- and that is after all the tear down etc. I think it's fine if the epilogue marker is inexact or missing from optimized code, because (1) that's the current state, and (2) it doesn't really make sense to talk about an epilogue in some cases. Similarly, IMO it is fine not to worry about non-local exits. You can already catch exceptions and examine them in gdb -- the epilogue marker feature is mostly to address the unmet need of wanting to set a breakpoint at the end of a function. Ideally, in -O0 / -Og code, the marker would be reliable where it appears. It would be great if there was a way to indicate the location of the value-to-be-returned in the DWARF. That way gdb could extract it at the epilogue point. AFAIK this would require a DWARF extension. thanks, Tom ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Indicating function exit points in debug data 2019-03-20 19:05 ` Tom Tromey @ 2019-03-21 8:23 ` Richard Biener 2019-03-21 9:11 ` Justin Paston-Cooper 0 siblings, 1 reply; 14+ messages in thread From: Richard Biener @ 2019-03-21 8:23 UTC (permalink / raw) To: Tom Tromey; +Cc: Segher Boessenkool, Justin Paston-Cooper, GCC Development On Wed, Mar 20, 2019 at 8:05 PM Tom Tromey <tom@tromey.com> wrote: > > >>>>> "Segher" == Segher Boessenkool <segher@kernel.crashing.org> writes: > > >> Section 6.2.5.2 outlines the line number information state machine's > >> opcodes. One of them is "DW_LNS_set_epilogue_begin". Its definition > >> is: > > Segher> How should this work with shrink-wrapping? The whole point of that is > Segher> you do not tear down the frame after all other code, etc. I don't see > Segher> how we can do better than putting this DW_LNS_set_epilogue_begin right > Segher> before the actual return -- and that is after all the tear down etc. > > I think it's fine if the epilogue marker is inexact or missing from > optimized code, because (1) that's the current state, and (2) it doesn't > really make sense to talk about an epilogue in some cases. > > Similarly, IMO it is fine not to worry about non-local exits. You can > already catch exceptions and examine them in gdb -- the epilogue marker > feature is mostly to address the unmet need of wanting to set a > breakpoint at the end of a function. Btw, the feature I am missing is not breaking at the end of a function but conditionally breaking on a specific return value of a specific function. Those are probably related but my usecase might be easier because the return value location is defined by the ABI and catching the actual return assembly instruction should already work. > Ideally, in -O0 / -Og code, the marker would be reliable where it > appears. > > It would be great if there was a way to indicate the location of the > value-to-be-returned in the DWARF. That way gdb could extract it at the > epilogue point. AFAIK this would require a DWARF extension. The ABI specifies this at the 'ret' instruction? Richard. > thanks, > Tom ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Indicating function exit points in debug data 2019-03-21 8:23 ` Richard Biener @ 2019-03-21 9:11 ` Justin Paston-Cooper 2019-03-21 9:34 ` Justin Paston-Cooper 0 siblings, 1 reply; 14+ messages in thread From: Justin Paston-Cooper @ 2019-03-21 9:11 UTC (permalink / raw) To: Richard Biener; +Cc: Tom Tromey, Segher Boessenkool, GCC Development On Thu, 21 Mar 2019 at 08:23, Richard Biener <richard.guenther@gmail.com> wrote: > > On Wed, Mar 20, 2019 at 8:05 PM Tom Tromey <tom@tromey.com> wrote: > > > > >>>>> "Segher" == Segher Boessenkool <segher@kernel.crashing.org> writes: > > > > >> Section 6.2.5.2 outlines the line number information state machine's > > >> opcodes. One of them is "DW_LNS_set_epilogue_begin". Its definition > > >> is: > > > > Segher> How should this work with shrink-wrapping? The whole point of that is > > Segher> you do not tear down the frame after all other code, etc. I don't see > > Segher> how we can do better than putting this DW_LNS_set_epilogue_begin right > > Segher> before the actual return -- and that is after all the tear down etc. > > > > I think it's fine if the epilogue marker is inexact or missing from > > optimized code, because (1) that's the current state, and (2) it doesn't > > really make sense to talk about an epilogue in some cases. > > > > Similarly, IMO it is fine not to worry about non-local exits. You can > > already catch exceptions and examine them in gdb -- the epilogue marker > > feature is mostly to address the unmet need of wanting to set a > > breakpoint at the end of a function. > > Btw, the feature I am missing is not breaking at the end of a function > but conditionally breaking on a specific return value of a specific function. > Those are probably related but my usecase might be easier because > the return value location is defined by the ABI and catching the actual > return assembly instruction should already work. > > > Ideally, in -O0 / -Og code, the marker would be reliable where it > > appears. > > > > It would be great if there was a way to indicate the location of the > > value-to-be-returned in the DWARF. That way gdb could extract it at the > > epilogue point. AFAIK this would require a DWARF extension. > > The ABI specifies this at the 'ret' instruction? Would this still allow inspection of the function's final state, where it returns, apart from its return value? That is the original behaviour I had in mind. Also for completeness it would be nice if this feature supported inline functions too. 'ret' would not be a solution for that. From what Segher said, I understand that the 'epilogue_begin' marker is put right before the 'ret' instruction if it exists. Does gdb have another way of finding the real epilogue beginning, before registers are restored? > > Richard. > > > thanks, > > Tom ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Indicating function exit points in debug data 2019-03-21 9:11 ` Justin Paston-Cooper @ 2019-03-21 9:34 ` Justin Paston-Cooper 0 siblings, 0 replies; 14+ messages in thread From: Justin Paston-Cooper @ 2019-03-21 9:34 UTC (permalink / raw) To: Richard Biener; +Cc: Tom Tromey, Segher Boessenkool, GCC Development On Thu, 21 Mar 2019 at 09:11, Justin Paston-Cooper <paston.cooper@gmail.com> wrote: > > On Thu, 21 Mar 2019 at 08:23, Richard Biener <richard.guenther@gmail.com> wrote: > > > > On Wed, Mar 20, 2019 at 8:05 PM Tom Tromey <tom@tromey.com> wrote: > > > > > > >>>>> "Segher" == Segher Boessenkool <segher@kernel.crashing.org> writes: > > > > > > >> Section 6.2.5.2 outlines the line number information state machine's > > > >> opcodes. One of them is "DW_LNS_set_epilogue_begin". Its definition > > > >> is: > > > > > > Segher> How should this work with shrink-wrapping? The whole point of that is > > > Segher> you do not tear down the frame after all other code, etc. I don't see > > > Segher> how we can do better than putting this DW_LNS_set_epilogue_begin right > > > Segher> before the actual return -- and that is after all the tear down etc. > > > > > > I think it's fine if the epilogue marker is inexact or missing from > > > optimized code, because (1) that's the current state, and (2) it doesn't > > > really make sense to talk about an epilogue in some cases. > > > > > > Similarly, IMO it is fine not to worry about non-local exits. You can > > > already catch exceptions and examine them in gdb -- the epilogue marker > > > feature is mostly to address the unmet need of wanting to set a > > > breakpoint at the end of a function. > > > > Btw, the feature I am missing is not breaking at the end of a function > > but conditionally breaking on a specific return value of a specific function. > > Those are probably related but my usecase might be easier because > > the return value location is defined by the ABI and catching the actual > > return assembly instruction should already work. > > > > > Ideally, in -O0 / -Og code, the marker would be reliable where it > > > appears. > > > > > > It would be great if there was a way to indicate the location of the > > > value-to-be-returned in the DWARF. That way gdb could extract it at the > > > epilogue point. AFAIK this would require a DWARF extension. > > > > The ABI specifies this at the 'ret' instruction? > > Would this still allow inspection of the function's final state, where > it returns, apart from its return value? That is the original > behaviour I had in mind. Also for completeness it would be nice if > this feature supported inline functions too. 'ret' would not be a > solution for that. From what Segher said, I understand that the > 'epilogue_begin' marker is put right before the 'ret' instruction if > it exists. Does gdb have another way of finding the real epilogue > beginning, before registers are restored? I've looked at function.c a bit more, and I see what Segher is getting at. Also, given that a function might have multiple return statements pointing to a single 'ret' instruction, I'm not sure that 'ret' is the best solution. I also see that there will only be a single epilogue, so that would not be useful either. > > > > > Richard. > > > > > thanks, > > > Tom ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2019-03-21 9:34 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-03-19 20:38 Indicating function exit points in debug data Justin Paston-Cooper 2019-03-19 21:29 ` Florian Weimer 2019-03-19 21:41 ` Justin Paston-Cooper 2019-03-19 21:52 ` Florian Weimer 2019-03-19 22:20 ` Justin Paston-Cooper 2019-03-19 22:40 ` Florian Weimer 2019-03-19 22:52 ` Justin Paston-Cooper 2019-03-20 8:31 ` Richard Biener 2019-03-20 10:13 ` Justin Paston-Cooper 2019-03-20 17:36 ` Segher Boessenkool 2019-03-20 19:05 ` Tom Tromey 2019-03-21 8:23 ` Richard Biener 2019-03-21 9:11 ` Justin Paston-Cooper 2019-03-21 9:34 ` Justin Paston-Cooper
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).