In D102220#2755984, @MaskRay wrote:

In D102220#2755883, @RamNalamothu wrote:

In D102220#2755545, @MaskRay wrote:

the interfacing code in parsers and streamers are using both signed and unsigned type in different parts.

Where is uint64_t used? Most places use int64_t.

For instance in AsmParser::parseRegisterOrRegisterNumber() and type cast in MCStreamer::emitCFIDefCfaRegister().

In D102220#2755545, @MaskRay wrote:

the interfacing code in parsers and streamers are using both signed and unsigned type in different parts.

Where is uint64_t used? Most places use int64_t.

Add virtual method parseAbsoluteExpression(uint64_t) to MCAsmParser.

Missed changes in the previous update(s).

In D102220#2752089, @scott.linder wrote:

Would it be reasonable to just clean up all the types in these functions? I noted the ones I identified.

Address the review comments.

Handle the scenario when the CIE or FDE has only DW_CFA_nop instructions.

Does this look good now for commit?

Thank you.

Made the suggested code changes.

Update llvm/test/CodeGen/AMDGPU/debug_frame.ll test.

If there are no further comments, I will commit this once the build is completed.

Address feedback on LIT tests.

Fix llvm/test/CodeGen/AMDGPU/ptr-arg-dbg-value.ll failure on Windows.

Does it look good now?

In D78778#2729953, @aheejin wrote:

In D78778#2727655, @RamNalamothu wrote:

In D78778#2720397, @dblaikie wrote:

In D78778#2719704, @RamNalamothu wrote:

Fix couple of WebAsembly debug info LIT tests, as we now emit .debug_frame when no exceptions.

Hmm - was this intended to change the behavior of WebAssembly? Could you get someone with some WebAssembly context to double check this is desirable behavior?

Not intended but probably the LIT test updates are expected for WebAssembly. Adding @aheejin as well to review those.
Please note that those LIT tests are not explicitly checking for either presence/non-presense of .eh_frame or .debug_frame and might have just tried to match the compiler output back then.

However, while I still feel the current usesCFIForDebug() approach is in the right direction, please let me know if the preferred approach is a target configurable option and if yes, I can update this review with https://reviews.llvm.org/D101592 changes (not meant to be reviewed there).

I am not very familiar with these tests. Perhaps any of @aardappel @sbc100 @yurydelendik would know.

I found this case while working on https://reviews.llvm.org/D76877.

In D78778#2720397, @dblaikie wrote:

In D78778#2719704, @RamNalamothu wrote:

Fix couple of WebAsembly debug info LIT tests, as we now emit .debug_frame when no exceptions.

Hmm - was this intended to change the behavior of WebAssembly? Could you get someone with some WebAssembly context to double check this is desirable behavior?

Implemented the suggested improvement.

Fix couple of WebAsembly debug info LIT tests, as we now emit .debug_frame when no exceptions.

Address review comments.

@dblaikie wrote:
Sorry, paging this all back in. Why is this necessary? THis looks like the sort of change that would be necessary to allow /both/ eh_frame and debug_frame to be emitted at the same time. Is that what this is about? That doesn't seem to line up with my reading of the patch description, which seems to be about being able to emit debug_frame even when not using exceptions - but wouldn't require anything to say "I want eh_frame and debug_frame at the same time" I think?

Remove the changes that were committed seperately in https://reviews.llvm.org/D76519.

In D76519#2714352, @MaskRay wrote:

Refactor how CFI move sections

Since 'move' is coined term which is not accurate, just avoid using it.

Address review comments.

Does it look better now, after the renaming?

Renaming the state variables for better representation.

Scott, I will take this forward. Hope that is fine.

Rebase and ping

Incorporated the suggestions. Thank you.

Address feedback as suggested.

Address review comments.

I think I have addressed the feedback. Could you please take a look now?

Rebase onto ToT.

Rebase onto LLVM trunk and couple of bug fixes where we need to save FP due to CFI register spills but did not save it.

Rebase onto LLVM trunk.

Rebase onto LLVM trunk.

Rebase onto LLVM trunk.

Rebase and ping.

Rebase and extend the patch to cover https://reviews.llvm.org/rGf8122d35325d9a5d3db7d4c0d40bcdeae15bee5a.

Rebase and ping

LGTM

How does it look now, with some renaming I did?

In D76519#2452608, @MaskRay wrote:

As a potential follow-up, I do want the CFIMoveTypes concept to be better documented and probably rename it if it does not convey the intended meaning to readers.

In D78778#2444445, @dblaikie wrote:

(I'm probably not the best person to review this - just chimed in on the patch structure/testing issues, but here are some naive questions)

In D78778#2301155, @RamNalamothu wrote:

In D78778#2300827, @probinson wrote:

I haven't touched the streamer side of AsmPrinter in a long time, but...
On PS4 we default to -fno-exceptions and while the section ends up named .eh_frame instead of .debug_frame the content is fine; we've had no complaints from our debugger folks. Aside from the introduction of the .cfi directives (which you do want), I'm not aware that there's any codegen consequence to this combination.
So, I'm not clear why a special streamer is really necessary.

A special streamer is a straight forward and minimal changes approach we could arrive at as a means to solve the following concerns observed with the current implementation.

1. Today, with -fno-exceptions, the command line option --force-dwarf-frame-section of llc doesn't do what it should as per D67216 i.e. a .debug_frame is not generated

Does this change address (1)? Should there be a test for --force-dwarf-frame-section to demonstrate this fix? (what cases did D67216 address? that are distinct from this case that it misses)

Rebase onto LLVM master and address feedback

Rebase onto LLVM master and address feedback

Rebase onto LLVM master and address feedback

Rebase onto LLVM master and address feedback

Rebase onto LLVM Master

Rebase onto LLVM Master

Rebase onto LLVM master

Rebase on top of LLVM master

In D78778#2300827, @probinson wrote:

I haven't touched the streamer side of AsmPrinter in a long time, but...
On PS4 we default to -fno-exceptions and while the section ends up named .eh_frame instead of .debug_frame the content is fine; we've had no complaints from our debugger folks. Aside from the introduction of the .cfi directives (which you do want), I'm not aware that there's any codegen consequence to this combination.
So, I'm not clear why a special streamer is really necessary.

Rebase onto LLVM master. Tidy up code little bit and couple of fixes.
And also, handle cases where no free VGPR is available to spill into and we have to spill into memeory.