This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Remove the "MemoryHistory" plugin type and merge it into InstrumentationRuntime [NFC]
Needs RevisionPublic

Authored by kubamracek on Feb 15 2017, 2:16 PM.

Details

Summary

There is currently a single MemoryHistory plugin, which is for AddressSanitizer. Let's merge the feature into InstrumentationRuntime plugins. I'm thinking of implementing another provider of memory history, which would be for ThreadSanitizer -- and it would be weird to implement two separate plugins (MemoryHistory and InstrumentationRuntime) to each sanitizer.

This is NFC, just refactoring.

Diff Detail

Event Timeline

kubamracek created this revision.Feb 15 2017, 2:16 PM
kubamracek retitled this revision from [lldb] Remove the "MemoryHistory" plugin type and merge it into InstrumentationRuntime to [lldb] Remove the "MemoryHistory" plugin type and merge it into InstrumentationRuntime [NFC].Feb 16 2017, 9:16 PM
kubamracek edited the summary of this revision. (Show Details)
clayborg edited edge metadata.Mar 10 2017, 4:34 PM

Looks ok to me. Jim, are you ok with this? If Jim is OK with this, then I am.

jingham requested changes to this revision.Mar 10 2017, 5:18 PM

The InstrumentationRuntime implements a fairly specific model of something that might provide history threads. There has to be a module in the program that implements this, and a breakpoint that presumably triggers the report. What if you implemented this instead with dtrace behind the program's back? It wouldn't look like an InstrumentationRuntime plugin as currently sketched out.

This doesn't necessarily mean that the MemoryHistory has to stand separate from the InstrumentationRuntime. Maybe there should be a more general base for InstrumentationRuntime that has the notion of providing memory histories but is less specific about how it goes about doing so?

This revision now requires changes to proceed.Mar 10 2017, 5:18 PM
source/Target/CMakeLists.txt