Community
Participate
Working Groups
Created attachment 183710 [details] patch ModuleLineEntryProvider.java (and dependents) to improve cases of inline stepping inline stepping presents a number of problems that ModuleLineEntryProvider … and in particular internal ModuleLineEntryProvider$FileLineEntryProvider, which ModuleLineEntryProvider relies on heavily … fails to handle well. in particular, FileLineEntryProvider will have tables which may: - have gaps that are filled only by another provider - have a last entry that may not be at the end of the function, where the remainder of entries are in another provider when stepping "over", it can appear that the next line is further than it is, or that the current line is the last line when it is not. when stepping "into", nested inlines in files different that the source where the inline was invoked can be incorrectly skipped. when stepping "out", these same gaps may make it appear that the function is one level higher in scope than it really is. ModuleLineEntryProvider has an internal pathToLineEntryMap that appears meant to map all of the probable providers for a particular map, but the cross-matrix of such providers is not actually implemented completely. there are times that the current instruction pointer may point at code that's in a particular inlined file, and for the upcoming step, it may be necessary to learn the path to the parent, or it may be necessary to learn the path to a child, or it may be necessary to learn the path to a sibling. such connections are never established in pathToLineEntryMap. the attached patch attempts to deal with the complex logic of the variety of cases that exist with inline stepping, and does so partially by moving the entire burden of calculating the next line entry out of getLineEntryAtAddress() and into getNextLineEntry() and a new utility getLineEntryAtAddressInCU().
some of my additional detailed notes with regard to methodology. i've tried to define all abbreviations, but let me know if there's anything confusing. first: deal with the current line as an inline to be ignored at the time it is set up in StackFrameDMC . this is the entirety of the changes in Stack.java , described in Bug 330971 . second: deal with inlines during stepping primarily through the getNextEntry() calls rather than the getEntryAtAddress calls. once we've figured out properly where we're at w.r.t. StackFrameDMC, the current line entry matters less than where we are supposed to be establishing the boundary of a step over. this is the focus of the attachment for this bug. most important, perhaps, a matrix of how i attempted to confirm as many cases as possible. combine a currentLineEntry letter with a nextLineEntry number to see the cases below. f, x, & z are notations to deal with in each case. a: currentLineEntry == top, no inlines b: currentLineEntry == top, inlines other than 1st instr c: currentLineEntry == in inline, on 1st instr d: currentLineEntry == in inline, not on 1st instr 1: nextLineEntry == top 2: nextLineEntry == inline (same as currentLineEntry) 3: nextLineEntry == inline (child of currentLineEntry) 4: nextLineEntry == inline (sibling of currentLineEntry) 5: nextLineEntry == null (i.e. last line of function of currentLineEntry) annotations: f: for-loop x: same-file z: other-file conceptual solutions: LBA: lineEntriesByAddress LBL: lineEntriesByLine other abbreviations. CUS-FP: compileUnitScope.filePath EOI: end-of-inline if stepping into (i.e. !collapseInlineFunctions), always use LEBA for any case returning NULL, use end-of-function as endAddr a1: for {f}, must get 1st of LEBL from LEBA a2: ~ not applicable ~ a3: LEBL ({f} will not be applicable for {3}) a4: ~ not applicable ~ a5: null b1: for {f}, must get 1st of LEBL from LEBA b2: ~ not applicable ~ b3: LEBL ({f} will not be applicable for 3) b4: ~ not applicable ~ b5: null c1: try LEBL, but for {f}, must get 1st of LEBL from LEBA if LEBL-attempt encounters EOI, get CUS-FP.providers & force LEBA [*i, *ii] c2: try LEBL; if EOI, get CUS-FP.providers & force LEBA [*i, *iii] c3: try LEBL; if EOI, get CUS-FP.providers & force LEBA [*i, *iv] c4: try LEBL; if EOI, get CUS-FP.providers & force LEBA [*i, *v] c5: null d1: try LEBL, but for {f}, must get 1st of LEBL from LEBA if LEBL-attempt returns NULL, get CUS-FP.providers & force LEBA [*iii] d2: try LEBL; if EOI, get CUS-FP.providers & force LEBA [*iii] d3: try LEBL; if EOI, get CUS-FP.providers & force LEBA [*iv] d4: try LEBL; if EOI, get CUS-FP.providers & force LEBA [*v] d5: null footnotes: [*i] StackFrameDMC now does the calculation of the name based upon where it lands being 1st line of inline or not [*ii] LEBL covers this case so PC at 1st line of 1st inline may get to next line without inlines; backup LEBA covers EOI [*iii] LEBL orthogonal to this case; backup LEBA covers EOI [*iv] LEBL covers this case to step over nested inlines; backup LEBA covers EOI [*v] LEBL likely to cause EOI in this case; LEBA will get sibling finally, some leftover issues: A] note that {f} above intends to take for-loops into account. for-loop lopp stepping still "hiccups" when step-in where it does not for step-over. the root cause is probably how disabled ranges are established only for step-over. A.1] we might eventually be able to use the columns to make this stepping less transparent to the user. it would involve changing the highlight line … and possibly figuring out where the "end-column" is, since that's not provided currently B] step-out … there's always been separate code to handle stepping out of inlines. Bug 330972 addresses the case of stepping out from the first line of an inline so it matches what is shown in the Debug Stack view C] compilers could help performance (i.e. skipping edge-case calculation) C.1] generating inlines line entries with correct scope high address C.2] by not having inline line entries with addresses greater than the inline scope high address (i.e. properly assign post-inline clean-up to the parent) C.3] by placing end-of-loop line entries on closing loop brackets if possible C.4] by doing better about having a line-entry at start-of-epilog D] the case-statement stepping problem that was there is still there. it should not be affected by these changes. D.1] solution for ARM appears to be to do some magic in ARM_switch
(this is part of a batch change) The Eclipse CDT EDC (https://wiki.eclipse.org/CDT/cdt-debug-edc) is now obsolete and has not had any active development since 2011. Therefore the still open bugs are being marked as wontfix. The git repo for the project still exists for posterity at https://git.eclipse.org/c/cdt/org.eclipse.cdt.edc.git/
