295 lines
6.4 KiB
Plaintext
Raw Normal View History

SubDir HAIKU_TOP src apps debugger ;
CCFLAGS += -Werror ;
C++FLAGS += -Werror ;
UsePrivateHeaders app debug interface kernel shared libroot ;
UsePrivateSystemHeaders ;
# Use gdb's readline. It would be better to use an optional build feature.
UseHeaders [ FDirName $(HAIKU_TOP) src bin gdb ] : true ;
SEARCH_SOURCE += [ FDirName $(SUBDIR) arch ] ;
SEARCH_SOURCE += [ FDirName $(SUBDIR) arch x86 ] ;
SEARCH_SOURCE += [ FDirName $(SUBDIR) debug_info ] ;
SEARCH_SOURCE += [ FDirName $(SUBDIR) debugger_interface ] ;
SEARCH_SOURCE += [ FDirName $(SUBDIR) elf ] ;
SEARCH_SOURCE += [ FDirName $(SUBDIR) files ] ;
* Worker: - Made Job Referenceable. - Turned JobKey into an abstract base class to add flexibility. The new SimpleJobKey is a subclass with the former functionality. * TeamWindow: Removed the TeamWindow* parameter from the listener hooks. The TeamDebugger knows anyway. * Added IDs to Variable, Function, and FunctionInstance. The latter two generate the ID on the fly, Variable stores it. * SpecificImageDebugInfo::CreateFrame(): Changed FunctionDebugInfo* debug parameter to FunctionInstance* to provide more info (the function ID). * DwarfInterfaceFactory/DwarfImageDebugInfo: - Added class DwarfFunctionParameterID, an ID class implementation for function parameters and set the IDs on the parameter objects. - Retrieve the size of a type (i.e. the size of its objects) and store it in DwarfType. - If a parameter's ValueLocation doesn't have a size, set that of the respective type. - Map the register indicies in the parameters' ValueLocations from DWARF to our indices. * Added class TypeComponentPath for identifying subcomponents in types. * Added class StackFrameValues, a container associating variables and their subcomponents with values. * StackFrame does now have a StackFrameValues object for parameters and local variables and a mechanism to notify listeners when values have been retrieved. * Added GetStackFrameValueJob to retrieve variable values. Lots of functionality is missing yet. Most notably it doesn't retrieves values for subcomponents. * Wired everything to trigger loading of variable values and getting notified when done. * VariablesView: Added a value column. This is all very basic and has to be done differently, but at least values for the parameters can be seen already. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31636 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-07-18 23:52:16 +00:00
SEARCH_SOURCE += [ FDirName $(SUBDIR) ids ] ;
SEARCH_SOURCE += [ FDirName $(SUBDIR) model ] ;
SEARCH_SOURCE += [ FDirName $(SUBDIR) settings ] ;
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 18:15:21 +00:00
SEARCH_SOURCE += [ FDirName $(SUBDIR) settings generic ] ;
SEARCH_SOURCE += [ FDirName $(SUBDIR) source_language ] ;
SEARCH_SOURCE += [ FDirName $(SUBDIR) types ] ;
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 18:15:21 +00:00
SEARCH_SOURCE += [ FDirName $(SUBDIR) user_interface ] ;
SEARCH_SOURCE += [ FDirName $(SUBDIR) user_interface cli ] ;
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 18:15:21 +00:00
SEARCH_SOURCE += [ FDirName $(SUBDIR) user_interface gui ] ;
SEARCH_SOURCE += [ FDirName $(SUBDIR) user_interface gui inspector_window ] ;
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 18:15:21 +00:00
SEARCH_SOURCE += [ FDirName $(SUBDIR) user_interface gui model ] ;
SEARCH_SOURCE += [ FDirName $(SUBDIR) user_interface gui team_window ] ;
SEARCH_SOURCE += [ FDirName $(SUBDIR) user_interface gui teams_window ] ;
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 18:15:21 +00:00
SEARCH_SOURCE += [ FDirName $(SUBDIR) user_interface gui util ] ;
SEARCH_SOURCE += [ FDirName $(SUBDIR) user_interface gui value ] ;
SEARCH_SOURCE += [ FDirName $(SUBDIR) util ] ;
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 18:15:21 +00:00
SEARCH_SOURCE += [ FDirName $(SUBDIR) value ] ;
SEARCH_SOURCE += [ FDirName $(SUBDIR) value type_handlers ] ;
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 18:15:21 +00:00
SEARCH_SOURCE += [ FDirName $(SUBDIR) value value_handlers ] ;
SEARCH_SOURCE += [ FDirName $(SUBDIR) value value_nodes ] ;
SEARCH_SOURCE += [ FDirName $(SUBDIR) value values ] ;
local debugAnalyzerSources
= [ FDirName $(HAIKU_TOP) src apps debuganalyzer ] ;
SubDirHdrs [ FDirName $(SUBDIR) demangler ] ;
SubDirHdrs [ FDirName $(SUBDIR) dwarf ] ;
SubDirHdrs [ FDirName $(HAIKU_TOP) src bin debug ] ;
SubDirHdrs [ FDirName $(debugAnalyzerSources) gui ] ;
SourceHdrs
DwarfFunctionDebugInfo.cpp
DwarfImageDebugInfo.cpp
DwarfStackFrameDebugInfo.cpp
DwarfTeamDebugInfo.cpp
DwarfTypeFactory.cpp
DwarfTypes.cpp
: [ FDirName $(SUBDIR) dwarf ]
;
Application Debugger :
BreakpointManager.cpp
Debugger.cpp
Jobs.cpp
TeamMemoryBlockManager.cpp
TeamDebugger.cpp
ThreadHandler.cpp
Worker.cpp
# arch
Architecture.cpp
CpuState.cpp
InstructionInfo.cpp
Register.cpp
RegisterMap.cpp
# arch/x86
ArchitectureX86.cpp
CpuStateX86.cpp
# debug_info
BasicFunctionDebugInfo.cpp
DebuggerImageDebugInfo.cpp
DebuggerTeamDebugInfo.cpp
DwarfFunctionDebugInfo.cpp
DwarfImageDebugInfo.cpp
DwarfStackFrameDebugInfo.cpp
DwarfTeamDebugInfo.cpp
DwarfTypeFactory.cpp
DwarfTypes.cpp
Very much work in progress, not in a particularly working state. Haiku munged a good part of the source tree, so I rather get those changes into the repository before continuing. The general aim of the work is to deal with multiple instances of the same function, e.g. inlined or non-inlined inline functions or those weird duplicates gcc (4 at least) seems to be generating for no apparent reason. * Added classes FunctionInstance (wrapping FunctionDebugInfo) and Function. FunctionInstance represents a physical instance of a function (e.g. inlined function at a particular address). A Function collects all FunctionInstances referring to the same source code location. * Moved the SourceCode property from FunctionDebugInfo to Function accordingly. * Since SourceCode is no longer associated with a concrete function instance, several methods dealing with statements have been removed and the functionality has been provided through other means (e.g. TeamDebugModel or SpecificImageDebugModel). This part is not yet completed. * Introduced UserBreakpoint and UserBreakpointInstance. The user sets a breakpoint at a source code location, which is represented by a UserBreakpoint. Since that source location can be mapped to one address per instance of the respective function, UserBreakpoint has a UserBreakpointInstance per such function instance, which in turn refers to a Breakpoint (an actual breakpoint at an address). * Adjusted Breakpoint, BreakpointManager, and TeamDebugger accordingly. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31447 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-07-07 20:47:39 +00:00
Function.cpp
FunctionDebugInfo.cpp
Very much work in progress, not in a particularly working state. Haiku munged a good part of the source tree, so I rather get those changes into the repository before continuing. The general aim of the work is to deal with multiple instances of the same function, e.g. inlined or non-inlined inline functions or those weird duplicates gcc (4 at least) seems to be generating for no apparent reason. * Added classes FunctionInstance (wrapping FunctionDebugInfo) and Function. FunctionInstance represents a physical instance of a function (e.g. inlined function at a particular address). A Function collects all FunctionInstances referring to the same source code location. * Moved the SourceCode property from FunctionDebugInfo to Function accordingly. * Since SourceCode is no longer associated with a concrete function instance, several methods dealing with statements have been removed and the functionality has been provided through other means (e.g. TeamDebugModel or SpecificImageDebugModel). This part is not yet completed. * Introduced UserBreakpoint and UserBreakpointInstance. The user sets a breakpoint at a source code location, which is represented by a UserBreakpoint. Since that source location can be mapped to one address per instance of the respective function, UserBreakpoint has a UserBreakpointInstance per such function instance, which in turn refers to a Breakpoint (an actual breakpoint at an address). * Adjusted Breakpoint, BreakpointManager, and TeamDebugger accordingly. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31447 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-07-07 20:47:39 +00:00
FunctionInstance.cpp
GlobalTypeLookup.cpp
ImageDebugInfo.cpp
ImageDebugInfoProvider.cpp
NoOpStackFrameDebugInfo.cpp
SpecificImageDebugInfo.cpp
SpecificTeamDebugInfo.cpp
StackFrameDebugInfo.cpp
TeamDebugInfo.cpp
# debugger_interface
DebugEvent.cpp
DebuggerInterface.cpp
# elf
ElfFile.cpp
# files
FileManager.cpp
LocatableDirectory.cpp
LocatableEntry.cpp
LocatableFile.cpp
SourceFile.cpp
* Worker: - Made Job Referenceable. - Turned JobKey into an abstract base class to add flexibility. The new SimpleJobKey is a subclass with the former functionality. * TeamWindow: Removed the TeamWindow* parameter from the listener hooks. The TeamDebugger knows anyway. * Added IDs to Variable, Function, and FunctionInstance. The latter two generate the ID on the fly, Variable stores it. * SpecificImageDebugInfo::CreateFrame(): Changed FunctionDebugInfo* debug parameter to FunctionInstance* to provide more info (the function ID). * DwarfInterfaceFactory/DwarfImageDebugInfo: - Added class DwarfFunctionParameterID, an ID class implementation for function parameters and set the IDs on the parameter objects. - Retrieve the size of a type (i.e. the size of its objects) and store it in DwarfType. - If a parameter's ValueLocation doesn't have a size, set that of the respective type. - Map the register indicies in the parameters' ValueLocations from DWARF to our indices. * Added class TypeComponentPath for identifying subcomponents in types. * Added class StackFrameValues, a container associating variables and their subcomponents with values. * StackFrame does now have a StackFrameValues object for parameters and local variables and a mechanism to notify listeners when values have been retrieved. * Added GetStackFrameValueJob to retrieve variable values. Lots of functionality is missing yet. Most notably it doesn't retrieves values for subcomponents. * Wired everything to trigger loading of variable values and getting notified when done. * VariablesView: Added a value column. This is all very basic and has to be done differently, but at least values for the parameters can be seen already. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31636 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-07-18 23:52:16 +00:00
# ids
FunctionID.cpp
LocalVariableID.cpp
ObjectID.cpp
FunctionParameterID.cpp
# model
Breakpoint.cpp
DisassembledCode.cpp
FileSourceCode.cpp
Image.cpp
ImageInfo.cpp
SourceCode.cpp
StackFrame.cpp
* Worker: - Made Job Referenceable. - Turned JobKey into an abstract base class to add flexibility. The new SimpleJobKey is a subclass with the former functionality. * TeamWindow: Removed the TeamWindow* parameter from the listener hooks. The TeamDebugger knows anyway. * Added IDs to Variable, Function, and FunctionInstance. The latter two generate the ID on the fly, Variable stores it. * SpecificImageDebugInfo::CreateFrame(): Changed FunctionDebugInfo* debug parameter to FunctionInstance* to provide more info (the function ID). * DwarfInterfaceFactory/DwarfImageDebugInfo: - Added class DwarfFunctionParameterID, an ID class implementation for function parameters and set the IDs on the parameter objects. - Retrieve the size of a type (i.e. the size of its objects) and store it in DwarfType. - If a parameter's ValueLocation doesn't have a size, set that of the respective type. - Map the register indicies in the parameters' ValueLocations from DWARF to our indices. * Added class TypeComponentPath for identifying subcomponents in types. * Added class StackFrameValues, a container associating variables and their subcomponents with values. * StackFrame does now have a StackFrameValues object for parameters and local variables and a mechanism to notify listeners when values have been retrieved. * Added GetStackFrameValueJob to retrieve variable values. Lots of functionality is missing yet. Most notably it doesn't retrieves values for subcomponents. * Wired everything to trigger loading of variable values and getting notified when done. * VariablesView: Added a value column. This is all very basic and has to be done differently, but at least values for the parameters can be seen already. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31636 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-07-18 23:52:16 +00:00
StackFrameValues.cpp
StackFrameValueInfos.cpp
StackTrace.cpp
Statement.cpp
SymbolInfo.cpp
Very much work in progress, not in a particularly working state. Haiku munged a good part of the source tree, so I rather get those changes into the repository before continuing. The general aim of the work is to deal with multiple instances of the same function, e.g. inlined or non-inlined inline functions or those weird duplicates gcc (4 at least) seems to be generating for no apparent reason. * Added classes FunctionInstance (wrapping FunctionDebugInfo) and Function. FunctionInstance represents a physical instance of a function (e.g. inlined function at a particular address). A Function collects all FunctionInstances referring to the same source code location. * Moved the SourceCode property from FunctionDebugInfo to Function accordingly. * Since SourceCode is no longer associated with a concrete function instance, several methods dealing with statements have been removed and the functionality has been provided through other means (e.g. TeamDebugModel or SpecificImageDebugModel). This part is not yet completed. * Introduced UserBreakpoint and UserBreakpointInstance. The user sets a breakpoint at a source code location, which is represented by a UserBreakpoint. Since that source location can be mapped to one address per instance of the respective function, UserBreakpoint has a UserBreakpointInstance per such function instance, which in turn refers to a Breakpoint (an actual breakpoint at an address). * Adjusted Breakpoint, BreakpointManager, and TeamDebugger accordingly. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31447 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-07-07 20:47:39 +00:00
UserBreakpoint.cpp
Team.cpp
TeamMemory.cpp
TeamMemoryBlock.cpp
TeamTypeInformation.cpp
Thread.cpp
ThreadInfo.cpp
Type.cpp
* Worker: - Made Job Referenceable. - Turned JobKey into an abstract base class to add flexibility. The new SimpleJobKey is a subclass with the former functionality. * TeamWindow: Removed the TeamWindow* parameter from the listener hooks. The TeamDebugger knows anyway. * Added IDs to Variable, Function, and FunctionInstance. The latter two generate the ID on the fly, Variable stores it. * SpecificImageDebugInfo::CreateFrame(): Changed FunctionDebugInfo* debug parameter to FunctionInstance* to provide more info (the function ID). * DwarfInterfaceFactory/DwarfImageDebugInfo: - Added class DwarfFunctionParameterID, an ID class implementation for function parameters and set the IDs on the parameter objects. - Retrieve the size of a type (i.e. the size of its objects) and store it in DwarfType. - If a parameter's ValueLocation doesn't have a size, set that of the respective type. - Map the register indicies in the parameters' ValueLocations from DWARF to our indices. * Added class TypeComponentPath for identifying subcomponents in types. * Added class StackFrameValues, a container associating variables and their subcomponents with values. * StackFrame does now have a StackFrameValues object for parameters and local variables and a mechanism to notify listeners when values have been retrieved. * Added GetStackFrameValueJob to retrieve variable values. Lots of functionality is missing yet. Most notably it doesn't retrieves values for subcomponents. * Wired everything to trigger loading of variable values and getting notified when done. * VariablesView: Added a value column. This is all very basic and has to be done differently, but at least values for the parameters can be seen already. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31636 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-07-18 23:52:16 +00:00
TypeComponentPath.cpp
TypeLookupConstraints.cpp
Variable.cpp
# settings
BreakpointSetting.cpp
GUITeamUISettings.cpp
SettingsManager.cpp
TeamSettings.cpp
TeamUISettings.cpp
TeamUISettingsFactory.cpp
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 18:15:21 +00:00
# settings/generic
Setting.cpp
Settings.cpp
SettingsDescription.cpp
# source_language
CLanguage.cpp
CLanguageFamily.cpp
CppLanguage.cpp
SourceLanguage.cpp
SyntaxHighlighter.cpp
UnsupportedLanguage.cpp
X86AssemblyLanguage.cpp
# types
ArrayIndexPath.cpp
TargetAddressRangeList.cpp
ValueLocation.cpp
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 18:15:21 +00:00
# user_interface
UserInterface.cpp
# user_interface/cli
CliCommand.cpp
CliContext.cpp
CommandLineUserInterface.cpp
# user_interface/gui
GraphicalUserInterface.cpp
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 18:15:21 +00:00
# user_interface/gui/model
VariablesViewState.cpp
VariablesViewStateHistory.cpp
# user_interface/gui/inspector_window
InspectorWindow.cpp
MemoryView.cpp
# user_interface/gui/teams_window
TeamsWindow.cpp
TeamsListView.cpp
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 18:15:21 +00:00
# user_interface/gui/team_window
BreakpointListView.cpp
BreakpointsView.cpp
ImageFunctionsView.cpp
ImageListView.cpp
RegistersView.cpp
SourceView.cpp
StackTraceView.cpp
TeamWindow.cpp
ThreadListView.cpp
VariablesView.cpp
# user_interface/gui/util
ActionMenuItem.cpp
GUISettingsUtils.cpp
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 18:15:21 +00:00
SettingsMenu.cpp
TargetAddressTableColumn.cpp
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 18:15:21 +00:00
# user_interface/gui/value
TableCellBoolRenderer.cpp
TableCellEnumerationRenderer.cpp
TableCellFloatRenderer.cpp
TableCellIntegerRenderer.cpp
TableCellStringRenderer.cpp
TableCellValueRenderer.cpp
TableCellValueRendererUtils.cpp
# util
ArchivingUtils.cpp
* Worker: - Made Job Referenceable. - Turned JobKey into an abstract base class to add flexibility. The new SimpleJobKey is a subclass with the former functionality. * TeamWindow: Removed the TeamWindow* parameter from the listener hooks. The TeamDebugger knows anyway. * Added IDs to Variable, Function, and FunctionInstance. The latter two generate the ID on the fly, Variable stores it. * SpecificImageDebugInfo::CreateFrame(): Changed FunctionDebugInfo* debug parameter to FunctionInstance* to provide more info (the function ID). * DwarfInterfaceFactory/DwarfImageDebugInfo: - Added class DwarfFunctionParameterID, an ID class implementation for function parameters and set the IDs on the parameter objects. - Retrieve the size of a type (i.e. the size of its objects) and store it in DwarfType. - If a parameter's ValueLocation doesn't have a size, set that of the respective type. - Map the register indicies in the parameters' ValueLocations from DWARF to our indices. * Added class TypeComponentPath for identifying subcomponents in types. * Added class StackFrameValues, a container associating variables and their subcomponents with values. * StackFrame does now have a StackFrameValues object for parameters and local variables and a mechanism to notify listeners when values have been retrieved. * Added GetStackFrameValueJob to retrieve variable values. Lots of functionality is missing yet. Most notably it doesn't retrieves values for subcomponents. * Wired everything to trigger loading of variable values and getting notified when done. * VariablesView: Added a value column. This is all very basic and has to be done differently, but at least values for the parameters can be seen already. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31636 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-07-18 23:52:16 +00:00
BitBuffer.cpp
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 18:15:21 +00:00
IntegerFormatter.cpp
StringUtils.cpp
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 18:15:21 +00:00
# value
TypeHandler.cpp
TypeHandlerRoster.cpp
Value.cpp
ValueHandler.cpp
ValueHandlerRoster.cpp
ValueLoader.cpp
ValueNode.cpp
ValueNodeContainer.cpp
# value/type_handlers
BMessageTypeHandler.cpp
CStringTypeHandler.cpp
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 18:15:21 +00:00
# value/value_handlers
AddressValueHandler.cpp
BoolValueHandler.cpp
EnumerationValueHandler.cpp
FloatValueHandler.cpp
IntegerValueHandler.cpp
StringValueHandler.cpp
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 18:15:21 +00:00
# value/value_nodes
AddressValueNode.cpp
ArrayValueNode.cpp
BMessageValueNode.cpp
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 18:15:21 +00:00
CompoundValueNode.cpp
CStringValueNode.cpp
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 18:15:21 +00:00
EnumerationValueNode.cpp
PointerToMemberValueNode.cpp
PrimitiveValueNode.cpp
VariableValueNodeChild.cpp
# value/values
AddressValue.cpp
BoolValue.cpp
EnumerationValue.cpp
FloatValue.cpp
IntegerValue.cpp
StringValue.cpp
* EnumerationValue -> EnumeratorValue * Since some types don't have names (e.g. pointer types or anonymous structs or unions), each type does now also have a unique ID. The global type cache registers types by ID and by name (if they have one). This fixes clashes of types with empty names. * Completely refactored the code dealing with variable values. Formerly we had Variable and TypeComponentPath to navigate to a component, mapped to a BVariant representing the value. Now we have: * Interface Value with various subclasses (BoolValue, IntegerValue, etc.) to represent a value, with the flexibility for more esoteric values. * A tree of ValueNode+ValueNodeChild objects to represent the components of a variable. On top of each ValueNodeChild sits a ValueNode representing the value of the component, potentially having ValueNodeChild children. This should allow casting a component value, simply by replacing its ValueNode. * Interface ValueHandler and various implementations for the different value types. It is basically a factory for classes allowing to format/display a value. * ValueHandlerRoster -- a registry for ValueHandlers, finding the best one for a given value. * Interface TypeHandler and various implementions for the different type kinds (primitive, compound, address, etc.). It is basically a factory for ValueNodes for that type. * TypeHandlerRoster -- a registry for TypeHandlers, finding the best one for a given type. That's still a bit work in progress. It introduces at least one regression: The VariablesView doesn't save/restore its state anymore. Will take a while until that is added back. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33907 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-11-05 18:15:21 +00:00
:
<nogrist>Debugger_demangler.o
<nogrist>Debugger_disasm_x86.o
<nogrist>Debugger_dwarf.o
<nogrist>DebugAnalyzer_gui_table.o
libudis86.a
<bin>debug_utils.a
libcolumnlistview.a
libshared.a
libshared.a
libexpression_parser.a
libmapm.a
<gdb>libreadline.a
libtermcap.a
$(TARGET_LIBSTDC++)
be tracker libdebug.so
: Debugger.rdef
;
HaikuSubInclude arch x86 disasm ;
HaikuSubInclude demangler ;
HaikuSubInclude dwarf ;