The existing code handles this correctly and I checked that the code
in NativeInlineSiteSymbol also handles this correctly, but it was
wrong in the NativeFunctionSymbol code.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I haven't added any tests here; I could upload an msvc-built binary for testing this. Not sure if that's necessary?
Well, I *can* think of a way to test this from a .s file. Instead of using .cv_inline_line_table, you could use a sequence of .byte 0xNN, 0xNN directives. I think you can get the hex codes from llvm-pdbutil dump -symbols. How about it?
llvm/lib/DebugInfo/PDB/Native/NativeFunctionSymbol.cpp | ||
---|---|---|
81 | I see. LLVM never uses this opcode. If this opcode is used to create a gap in the inlined call site, CodeOffset will be incorrect after the gap. |
How does this work? If I just add .bytes they turn into instructions. Or does it need to start with a particular .byte sequence?
If you set up a regular S_INLINESITE record in codeview, and then replace the .cv_inline_line_table directive with raw bytes, you can more finely control the opcodes used to produce the binary annotations. You'd get rid of the associated .cv_loc directives for the inline site as well.
I see. LLVM never uses this opcode. If this opcode is used to create a gap in the inlined call site, CodeOffset will be incorrect after the gap.