[ICF] Add a NOP after branch in ICF thunk to improve debugability #154986
Conversation
Signed-off-by: Peter Rong <[email protected]>
Signed-off-by: Peter Rong <[email protected]>
Signed-off-by: Peter Rong <[email protected]>
| @@ -1913,7 +1913,6 @@ void AsmPrinter::emitFunctionBody() { | |||
|
|
|||
| // Print out code for the function. | |||
| bool HasAnyRealCode = false; | |||
| int NumInstsInFunction = 0; | |||
There was a problem hiding this comment.
NumInstsInFunction was already calculated for debugging purposes. We just promote them as a class member to help us determine if DW_AT_LLVM_stmt_sequence should be emitted.
|
So far as I know, one instruction sequences are fine - /zero/ instruction sequences are problematic. Is this about one instruction, or zero instruction? Could you say more about what problems one instruction sequences have? I had trouble following info on the linked PR #154851 - it says things like "LowPC == HighPC" - but that shouldn't be the case for a single instruction sequence, right? (I'd have expected: LowPC + sizeof(instruction) + 1 == HighPC) |
|
@dwblaikie Thanks for taking a look, here's more explanation, hopefully it helps:
One instruction and one instruction only.
Ideally, it shouldn't. But this is the case right now. HighPC is the last row's address, which means for one-instruction sequences, the last row is the first row, and thus HighPC and LowPC are the same.
This is what #154851 trying to achieve/fix by setting
As mentioned above, one-instruction won't be its own sequence. But normally that's fine. The problem is specific to safe-thunk ICF and DW_AT_LLVM_stmt_sequence:
Combining 1 and 2 creates a new problem: when one-instruction is not its own sequence, we can't correctly insert such offset. |
Ranges are half open - so the last row's address should be one past the last instruction, see here for example: https://godbolt.org/z/ffP17MPaP A single instruction function (containts a single x86 ret instruction) has two entries in the line table: |
|
Thanks for pointing that out! But if you have three consecutive one-instruction functions (which would be a common case if you enable ICF safe thunks), they will be concat into one sequence: https://godbolt.org/z/GhrYP8njv The problem we have here is, for ICF thunks to be probably symbolicated, each function needs to be its own sequence when we enable In this case, we cannot just advance PC, or it will go into other thunks. |
I'm pretty sure this table is incorrect/buggy - it contains duplicate entries for the same offset. It describes zero-length, not one-length sequences. 3 single-instruction functions with separate sequences should be emitted like this: |
|
(if the functions have padding to force 0x10 alignment, then their ranges can be [0, 1) or [0, 2) up to [0, 10) - any of those values would be OK, doesn't matter if the padding is included in the function or not) In reality, if you build this example and actually link it (not sure how to then dwarfdump that on godbolt, so you'll have to do this locally): |
I agree, if the last row's address is not considered as part of the Sequence, it shouldn't bother with symbolication. If we agree that its |
|
FYI: @dwblaikie Seems you guys had a similar discussion a year ago |
Thanks for dredging up the history, perhaps it's informative to you/your work now.
That still sounds like a bit of a dodgy workaround for some more fundamental problem - we know how long the instruction is, we can produce a sequence that properly describes it (as can be seen in other single-instruction examples, with |
|
Closed since #157529 fixed the root cause |
### Context #99710 introduced `.loc_label` so we can terminate a line sequence. However, it did not advance PC properly. This is problematic for 1-instruction functions as it will have zero-length sequence. The test checked in that PR shows the problem: ``` # CHECK-LINE-TABLE: Address Line Column File ISA Discriminator OpIndex Flags # CHECK-LINE-TABLE-NEXT: ------------------ ------ ------ ------ --- ------------- ------- ------------- # CHECK-LINE-TABLE-NEXT: 0x00000028: 05 DW_LNS_set_column (1) # CHECK-LINE-TABLE-NEXT: 0x0000002a: 00 DW_LNE_set_address (0x0000000000000000) # CHECK-LINE-TABLE-NEXT: 0x00000035: 01 DW_LNS_copy # CHECK-LINE-TABLE-NEXT: 0x0000000000000000 1 1 1 0 0 0 is_stmt # CHECK-LINE-TABLE-NEXT: 0x00000036: 00 DW_LNE_end_sequence # CHECK-LINE-TABLE-NEXT: 0x0000000000000000 1 1 1 0 0 0 is_stmt end_sequence ``` Both rows having PC 0x0 is incorrect, and parsers won't be able to parse them. See more explanation why this is wrong in #154851. ### Design This PR attempts to fix this by advancing the PC to the next available Label, and advance to the end of the section if no Label is available. ### Implementation - `emitDwarfLineEndEntry` will advance PC to the `CurrLabel` - If `CurrLabel` is null, its probably a fake LineEntry we introduced in #110192. In that case look for the next Label - If still not label can be found, use `null` and `emitDwarfLineEndEntry` is smart enough to advance PC to the end of the section - Rename `LastLabel` to `PrevLabel`, "last" can mean "previous" or "final", this is ambigous. - Updated the tests to emit a correct label. ### Note This fix should render #154986 and #154851 obsolete, they were temporary fixes and don't resolve the root cause. --------- Signed-off-by: Peter Rong <[email protected]>
One-instruction functions are not considered as a
Sequenceof instructions in the eye of DebugInfo, this has made the debugability of an ICF'ed function really poor. Both verification #152807 and relocation #149618 of debug info are hard because of it.We have two options moving forward:
For design discussions / more context please move to #154851