Previously we assume there're some non-executing sections at the bottom of the text section so that we won't hit the array's bound. But on BOLTed binary, it turned out .bolt section is at the bottom of text section which can be profiled, then it crash llvm-profgen. This change try to fix it.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/tools/llvm-profgen/ProfileGenerator.cpp | ||
---|---|---|
358 | So this is fixing a separate bug? And ranges end is actually endOffset + 1? If that's the case, some comments for RangesTy Ranges would be helpful. | |
388–391 | Before the loop, RangeBegin <= RangeEnd should be guaranteed, right? Would this look cleaner? do { ... } while (IP.advance() && IP.Address <= RangeEnd); |
llvm/tools/llvm-profgen/ProfileGenerator.cpp | ||
---|---|---|
358 | Yeah, a separate bug. Remembering that RangesTy's end is exclusive. Still kind of related with this patch, because the extra one byte only can cause the out bounds issue. Will add some comments. |
llvm/tools/llvm-profgen/ProfileGenerator.cpp | ||
---|---|---|
388–391 | Seems not guaranteed, see the comments: // Disjoint ranges may have range in the middle of two instr, // e.g. If Instr1 at Addr1, and Instr2 at Addr2, disjoint range // can be Addr1+1 to Addr2-1. We should ignore such range. if (IP.Address > RangeEnd) continue; or change to ? if (IP.Address > RangeEnd) continue; do { ... } while (IP.advance() && IP.Address <= RangeEnd); |
llvm/tools/llvm-profgen/ProfileGenerator.cpp | ||
---|---|---|
388–391 | Ok, I see. Yeah, that works. We could have if (RangeStart > RangeEnd) check before constructing the IP, and together with that comment. |
llvm/tools/llvm-profgen/ProfileGenerator.cpp | ||
---|---|---|
358 | This is indeed error prone. The end range in DWARF is exclusive but the input using by findDisjointRanges is required to be inclusive. | |
388–391 | This is tricky. In this case, RangeStart is actually < RangeEnd but IP.Address is > RangeEnd, because IP.Address is round to next valid instruction. On a second thought, I'm wondering if we can remove the code with InstructionPointer. you see here it convert Offset --> Address then convert back to Offset. this seems redundant. I'm trying to work on Offset directly. |
llvm/tools/llvm-profgen/ProfileGenerator.cpp | ||
---|---|---|
388–391 |
Ah I see.. thanks for clarification.
I'm still leaning towards keep such indexing details under some abstraction, and in this case, IP. Not too worried about the Addr -> offset conversion. Or if the conversion is a concern, perhaps we can change IP to store Offset by default instead of virtual address, since majority of the use is with Offset. |
llvm/tools/llvm-profgen/ProfileGenerator.cpp | ||
---|---|---|
388–391 | I see. If we changing to use Offset by default, it seems a lot code need to change in the unwinder where it heavily uses Address . If the conversion is fine, I can just change back to use address like previous version. |
lgtm, thanks.
llvm/tools/llvm-profgen/ProfiledBinary.cpp | ||
---|---|---|
679–680 | Similarly, would be nice to use abstractions here instead of dealing with index directly. |
Updating D113238: [llvm-profgen] Fix index out of bounds error while using ip.advance
So this is fixing a separate bug? And ranges end is actually endOffset + 1? If that's the case, some comments for RangesTy Ranges would be helpful.