Page MenuHomePhabricator

[DebugInfo] Generate fixups as emitting DWARF .debug_line.

Authored by HsiangKai on May 14 2018, 2:13 PM.



It is necessary to generate fixups in .debug_line as relaxation is
enabled due to the address delta may be changed after relaxation.

DWARF will record the mappings of lines and addresses in
.debug_line section. It will encode the information using special
opcodes, standard opcodes and extended opcodes in 'Line Number
Program'. I use DW_LNS_fixed_advance_pc to encode fixed length
address delta and DW_LNE_set_address to encode absolute address
to make it possible to generate fixups in .debug_line section.

Diff Detail


Event Timeline

HsiangKai created this revision.May 14 2018, 2:13 PM
probinson added inline comments.
951 ↗(On Diff #146686)

Why not cast<MCBinaryExpr> and skip the assertion?

HsiangKai marked an inline comment as done.
asb added a subscriber: echristo.

@echristo: Do you think you might be able to help review this?

By way of background: RISC-V compilers are strongly encouraged to make use of linker relaxation. The compiler might generate a pair of instructions to call a function, but the linker may be able to delete one once the final code layout is known. In order for the linker to do this, relocations must be generated for everything - local control flow, symbol differences, debug info.

Create a simple slide to describe the problem in current LLVM implementation.
If there is no relocation in .debug_line, the program will be undebuggable after relaxation.

It looks to me like the line-table emitted by the new path would be valid. But I am not comfortable reviewing things related to MCExprs and fragments.

It looks to me like the line-table emitted by the new path would be valid. But I am not comfortable reviewing things related to MCExprs and fragments.

In original implementation, it is not expected to have fixups in MCDwarfLineAddrFragment, so it is derived from MCFragment. However, I want to put fixups in MCDwarfLineAddrFragment, so I change the parent of it to MCEncodedFragmentWithFixups.

Is there any suggestion for the implementation?

I have spent a little time familiarizing myself with the fragment stuff, which prompts the inline questions.
If you agree with my point about not having two places to store the fragment contents, then I think the first step would be to do that NFC refactoring to change the base class, and follow that with the change to handle the fixups for fixed advance.

510 ↗(On Diff #148346)

These template parameters will reserve 32 bytes for the content of the fragment and 4 MCFixups. Are these reasonable values? I see there is a SmallString<8> Contents; field in this class already, and it would appear that each MCDwarfLineAddrFragment would have at most one fixup.
If the new parent class is going to reserve memory for the contents, it seems like there is some additional refactoring needed to avoid a pointless increase in memory consumption.

HsiangKai marked an inline comment as done.Jul 31 2018, 10:06 AM

Refactoring done.

This revision is now accepted and ready to land.Jul 31 2018, 10:25 AM
This revision was automatically updated to reflect the committed changes.