Testing with debuggers shows that our previous behavior was correct.
The reason I thought MSVC did things differently is that MSVC prefers to
use the 0xB combined code offset and code length update opcode when
inline sites are discontiguous.
Keep the test changes, and update the llvm-pdbutil inline line table
dumper to account for this new interpretation of the opcodes.
llvm-svn: 362277
After improving the inline line table dumper in llvm-pdbutil and looking
at MSVC's inline line tables, it is clear that setting the length of the
inlined code region does not update the code offset. This means that the
delta to the beginning of a new discontiguous inlined code region should
be calculated relative to the last code offset, excluding the length.
Implementing this is a one line fix for MC: simply don't update
LastLabel.
While I'm updating these test cases, switch them to use llvm-objdump -d
and llvm-pdbutil. This allows us to show offsets of each instruction and
correlate the line table offsets to the actual code.
llvm-svn: 362264
We use both -long-option and --long-option in tests. Switch to --long-option for consistency.
In the "llvm-readelf" mode, -long-option is discouraged as it conflicts with grouped short options and it is not accepted by GNU readelf.
While updating the tests, change llvm-readobj -s to llvm-readobj -S to reduce confusion ("s" is --section-headers in llvm-readobj but --symbols in llvm-readelf).
llvm-svn: 359649
Previously we followed the DWARF implementation, which waits until the
next instruction or data to emit the label to use in the .debug_loc
section. We might want to consider re-evaluating that design choice as
well, since it means the .loc skips alignment padding, for better or
worse.
This was the most minimal fix I could come up with, but we should be
able to do a lot of cleanups now that we don't need to save a pending CV
location on the CodeViewContext. I plan to do those next, but this
immediately fixes an assertion for some of our users.
llvm-svn: 340878
Fangrui Song