DWARF: Update Ranges #2612
DWARF: Update Ranges #2612
Conversation
|
Imagine that we have a sequence of two It's possible |
|
Ah, got it. I guess if just an internal subrange were eliminated it would just work. what about if the beginning or end subrange is gone? I guess a downside of using real compiler output as test input is that we can't handpick edge cases. |
|
Not sure what you mean by "beginning subrange" - is that |
| newEnd = 0; | ||
| // If this was not an end marker, try to find what it should be updated to. | ||
| if (oldStart != 0 && oldEnd != 0) { | ||
| if (locationUpdater.hasOldExprAddr(oldStart)) { |
There was a problem hiding this comment.
should we have some kind of combined lookup like hasOldExprOrFuncStartAddr() ? I guess when updating ranges we have no way to tell the context of the use...
There was a problem hiding this comment.
I could refactor a function for this, but I don't think that would be reusable anywhere else. This is the one place where we update both sides of a span (start, end) at once.
There was a problem hiding this comment.
For the second part, yeah, we can't tell the context atm. If the context would help I could work on getting it. However, I think it should be safe as it is, as we do have the context of whether we are at the start or end of a span, and the risky thing is just the ambiguity of the end of one thing which is equal to the start of the next, which we avoid here.
| } else if (locationUpdater.hasOldFuncEndAddr(oldEnd)) { | ||
| newEnd = locationUpdater.getNewFuncEndAddr(oldEnd); | ||
| } | ||
| if (newStart == 0 || newEnd == 0) { |
There was a problem hiding this comment.
I guess in answer to my earlier question, If we have a range that represents a run of several instructions and we eliminate the last, I guess we don't have a good way to do "nearby" lookups in our current data structure.
|
by "beginning subrange" I meant e.g. [10, 15) |
|
I see now, thanks. Yeah, we could try to split subranges like |
|
Yeah, that might be the point where it makes more sense to just take the LLVM-style metadata approach (i.e. the debug info symbolically refers to IR constructs like functions and expressions) and regenerate it from scratch. |
Pretty straightforward given all we have so far. Note that fannkuch3_manyopts has an example of a sequence of ranges of which some must be skipped while others must not, showing we handle that by skipping the bad ones and updating the remaining. That is, if that we have a sequence of two (begin, end) spans [(10, 20), (30, 40)] It's possible (10, 20) maps in the new binary to (110, 120) while (30, 40) was eliminated by the optimizer and we have nothing valid to map it to. In that case we emit [(110, 120)]
Pretty straightforward given all we have so far.
Note that fannkuch3_manyopts has an example of
a sequence of ranges of which some must be skipped
while others must not, showing we handle that by
skipping the bad ones and updating the remaining.