This is an archive of the discontinued LLVM Phabricator instance.

Add an alternative CFA type.
ClosedPublic

Authored by jhibbits on Nov 8 2014, 6:16 PM.

Details

Summary

PowerPC handles the stack chain with the current stack pointer being a pointer
to the backchain (CFA). LLDB currently has no way of handling this, so this
adds a "CFA is dereferenced from a register" type.

Discussed with Jason Molenda, who also provided the initial patch for this.

Diff Detail

Repository
rL LLVM

Event Timeline

jhibbits updated this revision to Diff 15955.Nov 8 2014, 6:16 PM
jhibbits retitled this revision from to Add an alternative CFA type..
jhibbits updated this object.
jhibbits edited the test plan for this revision. (Show Details)
jhibbits added a reviewer: jasonmolenda.
jhibbits added a subscriber: Unknown Object (MLST).
emaste added a subscriber: emaste.Nov 8 2014, 6:37 PM
jasonmolenda requested changes to this revision.Nov 9 2014, 1:19 AM
jasonmolenda edited edge metadata.

Looks good, some very minor comments inlined, fine to commit after those are tweaked. Have you tried exercising the code? Either with an architecture default unwindplan in your ABI or with your eh_frame parser? I'd like to know that it actually works for you. :)

source/Plugins/Process/Utility/RegisterContextLLDB.cpp
1422 ↗(On Diff #15955)

I don't see cfa_regnum being used in this code block.

1426 ↗(On Diff #15955)

I think ReadCFAValueForRow should add active_row->GetCFAOffset to the cfa register value itself (and the same thing up at line 575 for the previous call to ReadCFAValueForRow. I bet you can drop the cfa_regval variable entirely and just have m_cfa. This will break some UnwindLogMsg calls -- but I think ReadCFAValueForRow() should UnwindLogMsg the CFA register value and offset if it's a reg+offset CFA.

1461 ↗(On Diff #15955)

When printing an addr_t, you should use PRIx64. e.g. "dereferenced address: 0x%" PRIx64 " yields: 0x%" PRIx64, tmp, value);". also, no \n at the end of UnwindLogMsgs.

source/Symbol/UnwindPlan.cpp
23 ↗(On Diff #15955)

I don't have any problem with the changes to UnwindPlan::Row::RegisterLocation::operator == - but what motivated this change? It seems like it's functionally the same. Am I missing something?

This revision now requires changes to proceed.Nov 9 2014, 1:19 AM

Looks good, some very minor comments inlined, fine to commit after those are tweaked. Have you tried exercising the code? Either with an architecture default unwindplan in your ABI or with your eh_frame parser? I'd like to know that it actually works for you. :)

I have both powerpc64 and powerpc32 unwinding with the default unwindplan now (to be committed separately). Past experience has taught me infrastructure first and separate when reviewing.

source/Plugins/Process/Utility/RegisterContextLLDB.cpp
1422 ↗(On Diff #15955)

Oops, missed this in my cleanup. In my first iteration I was passing discrete information, but changed to passing the row itself instead.

1426 ↗(On Diff #15955)

I debated doing this and went with the path of least code change, but wanted your opinion. Trivial for me to change it.

1461 ↗(On Diff #15955)

Gotcha. This started out as a debug printf for me that I changed to log and didn't update.

source/Symbol/UnwindPlan.cpp
23 ↗(On Diff #15955)

This was part of the patch you sent me. I ripped out a chunk that didn't compile, and moved it down to UnwindPlan::Row::operator==(), and was left with this. I'll revert this since it makes no sense to keep it as changed.

jhibbits updated this revision to Diff 15957.Nov 9 2014, 8:51 AM
jhibbits edited edge metadata.

Address Jason's comments

jasonmolenda accepted this revision.Nov 9 2014, 1:11 PM
jasonmolenda edited edge metadata.

Thanks, please commit.

This revision is now accepted and ready to land.Nov 9 2014, 1:11 PM
jhibbits closed this revision.Nov 12 2014, 7:14 AM
jhibbits updated this revision to Diff 16087.

Closed by commit rL221788 (authored by @jhibbits).