It happened that the LBR entry target can be the first address of text section which causes an out-of-range crash. So here add a boundary check.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/tools/llvm-profgen/PerfReader.cpp | ||
---|---|---|
65 | Why do we run into such cases? Is the profile corrupted? If that's the case, it may make sense to emit a warning about corrupted profile. As for the check itself, how about fold it into advance/backward, and let them return a boolean for caller to check? Index is implementation details of InstructionPoint and would be good to avoid using it from outside. |
llvm/tools/llvm-profgen/PerfReader.cpp | ||
---|---|---|
65 | Actually Index==0 is still valid, the problem is we cannot "backward" from index 0. However we still want to "recordRangeCount" if this index 0 is the end of the linear range. But the fix would skip "recordRangeCount" in end of range has index 0, which looks incorrect. Or am I missing something? |
llvm/tools/llvm-profgen/PerfReader.cpp | ||
---|---|---|
65 | Good point, Index 0 is missed then. The while loop here did compare the IP and next IP to see if they're in the same inline context or if we reach the end(target). I think the mixed logic is a little confusing. so I separate the logic letting the while loop only for inline check and after the loop we know it's the end and record the remaining range. BTW, some refactors is done for the address being used in switchToFrame, we can use any of the address in the range, so just use the End. |
llvm/tools/llvm-profgen/PerfReader.cpp | ||
---|---|---|
72 | This is a change beyond refactoring? Before, we use last address of old frame as frame address, but now it's going to be the first address of old frame. State.switchToFrame(LeafAddr); Or do did you actually meant State.switchToFrame(PrevIP);? |
llvm/tools/llvm-profgen/PerfReader.cpp | ||
---|---|---|
72 | It won't affect the result. I think any address in [PrevIP, End] is good for the leaf frame because we will trim the location info of the last frame. Using End is because End is also used out of the loop(just for readability). |
lgtm, thanks.
llvm/tools/llvm-profgen/PerfReader.cpp | ||
---|---|---|
72 | Ok, so it changes what's used in the frame trie, but as long as we use a consistent address to represent frame, changes there won't affect output, correct? |
llvm/tools/llvm-profgen/PerfReader.cpp | ||
---|---|---|
72 | Sorry, my fault, it should be the last address of the old frame, otherwise if the last address is a call, it will be recorded in the wrong callsite. Thanks for correcting me! |
llvm/tools/llvm-profgen/PerfReader.cpp | ||
---|---|---|
72 | OK, I double checked the call address won't use the address from linear unwinder, it use the LBR address. So changing to End should be fine. Anyway I choose use the last address which align to the program execution logic. |
Why do we run into such cases? Is the profile corrupted? If that's the case, it may make sense to emit a warning about corrupted profile.
As for the check itself, how about fold it into advance/backward, and let them return a boolean for caller to check? Index is implementation details of InstructionPoint and would be good to avoid using it from outside.