2009-06-14 12:53:29 +00:00
|
|
|
SubDir HAIKU_TOP src apps debugger ;
|
|
|
|
|
|
|
|
CCFLAGS += -Werror ;
|
|
|
|
C++FLAGS += -Werror ;
|
|
|
|
|
2011-06-12 20:51:27 +00:00
|
|
|
UsePrivateHeaders debug interface kernel shared libroot ;
|
2009-06-14 12:53:29 +00:00
|
|
|
UsePrivateSystemHeaders ;
|
|
|
|
|
2009-06-18 19:57:46 +00:00
|
|
|
SEARCH_SOURCE += [ FDirName $(SUBDIR) arch ] ;
|
|
|
|
SEARCH_SOURCE += [ FDirName $(SUBDIR) arch x86 ] ;
|
2009-06-20 17:20:49 +00:00
|
|
|
SEARCH_SOURCE += [ FDirName $(SUBDIR) debug_info ] ;
|
2009-06-18 17:57:37 +00:00
|
|
|
SEARCH_SOURCE += [ FDirName $(SUBDIR) debugger_interface ] ;
|
2009-06-27 21:09:21 +00:00
|
|
|
SEARCH_SOURCE += [ FDirName $(SUBDIR) elf ] ;
|
2009-07-01 22:09:33 +00:00
|
|
|
SEARCH_SOURCE += [ FDirName $(SUBDIR) files ] ;
|
2009-07-18 23:52:16 +00:00
|
|
|
SEARCH_SOURCE += [ FDirName $(SUBDIR) ids ] ;
|
2009-06-20 18:17:48 +00:00
|
|
|
SEARCH_SOURCE += [ FDirName $(SUBDIR) model ] ;
|
2009-07-24 02:35:30 +00:00
|
|
|
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 ] ;
|
2009-07-13 20:45:15 +00:00
|
|
|
SEARCH_SOURCE += [ FDirName $(SUBDIR) source_language ] ;
|
2009-06-29 22:38:15 +00:00
|
|
|
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 gui ] ;
|
2011-06-10 01:58:39 +00:00
|
|
|
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 ] ;
|
2010-09-21 15:07:48 +00:00
|
|
|
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 ] ;
|
2009-07-01 22:09:33 +00:00
|
|
|
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 ] ;
|
2010-11-09 01:06:32 +00:00
|
|
|
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 ] ;
|
2009-06-16 21:47:49 +00:00
|
|
|
|
|
|
|
local debugAnalyzerSources
|
|
|
|
= [ FDirName $(HAIKU_TOP) src apps debuganalyzer ] ;
|
|
|
|
|
2009-06-20 18:45:20 +00:00
|
|
|
SubDirHdrs [ FDirName $(SUBDIR) demangler ] ;
|
2010-12-11 19:05:54 +00:00
|
|
|
SubDirHdrs [ FDirName $(SUBDIR) dwarf ] ;
|
2009-06-16 21:47:49 +00:00
|
|
|
SubDirHdrs [ FDirName $(HAIKU_TOP) src bin debug ] ;
|
|
|
|
SubDirHdrs [ FDirName $(debugAnalyzerSources) gui ] ;
|
|
|
|
|
2009-06-27 23:40:32 +00:00
|
|
|
SourceHdrs
|
2009-06-29 22:38:15 +00:00
|
|
|
DwarfFunctionDebugInfo.cpp
|
2009-06-27 23:40:32 +00:00
|
|
|
DwarfImageDebugInfo.cpp
|
2009-09-21 04:39:40 +00:00
|
|
|
DwarfStackFrameDebugInfo.cpp
|
2009-06-27 23:40:32 +00:00
|
|
|
DwarfTeamDebugInfo.cpp
|
2009-10-10 05:05:33 +00:00
|
|
|
DwarfTypeFactory.cpp
|
|
|
|
DwarfTypes.cpp
|
2009-06-27 23:40:32 +00:00
|
|
|
: [ FDirName $(SUBDIR) dwarf ]
|
|
|
|
;
|
|
|
|
|
2009-06-14 12:53:29 +00:00
|
|
|
Application Debugger :
|
2009-06-25 23:51:09 +00:00
|
|
|
BreakpointManager.cpp
|
2009-06-16 21:47:49 +00:00
|
|
|
Debugger.cpp
|
2009-06-19 15:09:56 +00:00
|
|
|
Jobs.cpp
|
2011-06-10 01:58:39 +00:00
|
|
|
TeamMemoryBlockManager.cpp
|
2009-06-18 00:35:12 +00:00
|
|
|
TeamDebugger.cpp
|
2009-06-24 01:46:38 +00:00
|
|
|
ThreadHandler.cpp
|
2009-06-19 15:09:56 +00:00
|
|
|
Worker.cpp
|
2009-06-16 00:25:36 +00:00
|
|
|
|
2009-06-18 19:57:46 +00:00
|
|
|
# arch
|
|
|
|
Architecture.cpp
|
|
|
|
CpuState.cpp
|
2009-06-25 23:51:09 +00:00
|
|
|
InstructionInfo.cpp
|
2009-06-19 00:05:45 +00:00
|
|
|
Register.cpp
|
2009-07-13 18:45:49 +00:00
|
|
|
RegisterMap.cpp
|
2009-06-18 19:57:46 +00:00
|
|
|
|
|
|
|
# arch/x86
|
|
|
|
ArchitectureX86.cpp
|
|
|
|
CpuStateX86.cpp
|
2009-06-20 17:20:49 +00:00
|
|
|
|
|
|
|
# debug_info
|
|
|
|
BasicFunctionDebugInfo.cpp
|
2009-06-27 21:09:21 +00:00
|
|
|
DebuggerImageDebugInfo.cpp
|
|
|
|
DebuggerTeamDebugInfo.cpp
|
2009-06-29 22:38:15 +00:00
|
|
|
DwarfFunctionDebugInfo.cpp
|
2009-06-27 23:40:32 +00:00
|
|
|
DwarfImageDebugInfo.cpp
|
2009-09-21 04:39:40 +00:00
|
|
|
DwarfStackFrameDebugInfo.cpp
|
2009-06-27 23:40:32 +00:00
|
|
|
DwarfTeamDebugInfo.cpp
|
2009-10-10 05:05:33 +00:00
|
|
|
DwarfTypeFactory.cpp
|
|
|
|
DwarfTypes.cpp
|
2009-07-07 20:47:39 +00:00
|
|
|
Function.cpp
|
2009-06-20 17:20:49 +00:00
|
|
|
FunctionDebugInfo.cpp
|
2009-07-07 20:47:39 +00:00
|
|
|
FunctionInstance.cpp
|
* WIP regarding non comilation unit local types:
- Introduced GlobalTypeLookup interface and GlobalTypeLookupContext to look
up types by name and cache them.
- TeamDebugInfo implementes GlobalTypeLookup iterating through all
ImageDebugInfos, which in turn iterate through all SpecificImageDebugInfos.
- DwarfImageDebugInfo iterates through all compilation units, using
a temporary DwarfStackFrameDebugInfo to create the type.
- DwarfStackFrameDebugInfo no longer caches the types itself, but uses
GlobalTypeLookupContext. It uses GlobalTypeLookup to look up types not
defined in the compilation unit.
- DwarfFile: Made expression evaluation more robust, so that it also works,
when no subroutine entry, frame pointer, and instruction pointer are
available (and not used by the expression).
Basically works already, although the wrong compilation unit might be used
when resolving values for global types. It's also horribly slow, when there
are many types in the stack frame.
* DwarfStackFrameDebugInfo::ResolveArrayElementLocation(): The element location
piece size was set incorrectly (multiplied by 8, although bytes were
expected).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33477 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-10-07 03:17:22 +00:00
|
|
|
GlobalTypeLookup.cpp
|
2009-06-20 17:20:49 +00:00
|
|
|
ImageDebugInfo.cpp
|
|
|
|
ImageDebugInfoProvider.cpp
|
2009-09-21 04:39:40 +00:00
|
|
|
NoOpStackFrameDebugInfo.cpp
|
2009-06-27 21:09:21 +00:00
|
|
|
SpecificImageDebugInfo.cpp
|
|
|
|
SpecificTeamDebugInfo.cpp
|
2009-09-21 04:39:40 +00:00
|
|
|
StackFrameDebugInfo.cpp
|
2009-06-27 21:09:21 +00:00
|
|
|
TeamDebugInfo.cpp
|
2009-06-18 19:57:46 +00:00
|
|
|
|
|
|
|
# debugger_interface
|
|
|
|
DebugEvent.cpp
|
|
|
|
DebuggerInterface.cpp
|
2009-06-16 21:47:49 +00:00
|
|
|
|
2009-06-27 21:09:21 +00:00
|
|
|
# elf
|
|
|
|
ElfFile.cpp
|
|
|
|
|
2009-07-01 22:09:33 +00:00
|
|
|
# files
|
|
|
|
FileManager.cpp
|
|
|
|
LocatableDirectory.cpp
|
|
|
|
LocatableEntry.cpp
|
|
|
|
LocatableFile.cpp
|
2009-07-03 00:56:39 +00:00
|
|
|
SourceFile.cpp
|
2009-07-01 22:09:33 +00:00
|
|
|
|
2009-07-18 23:52:16 +00:00
|
|
|
# ids
|
|
|
|
FunctionID.cpp
|
|
|
|
LocalVariableID.cpp
|
|
|
|
ObjectID.cpp
|
|
|
|
FunctionParameterID.cpp
|
|
|
|
|
2009-06-20 18:17:48 +00:00
|
|
|
# model
|
2009-06-22 21:51:32 +00:00
|
|
|
Breakpoint.cpp
|
2009-06-22 01:13:57 +00:00
|
|
|
DisassembledCode.cpp
|
2009-07-03 00:56:39 +00:00
|
|
|
FileSourceCode.cpp
|
2009-06-20 18:17:48 +00:00
|
|
|
Image.cpp
|
|
|
|
ImageInfo.cpp
|
2009-06-21 13:17:21 +00:00
|
|
|
SourceCode.cpp
|
2009-06-20 18:17:48 +00:00
|
|
|
StackFrame.cpp
|
2009-07-18 23:52:16 +00:00
|
|
|
StackFrameValues.cpp
|
2009-09-21 04:39:40 +00:00
|
|
|
StackFrameValueInfos.cpp
|
2009-06-20 18:17:48 +00:00
|
|
|
StackTrace.cpp
|
2009-06-21 13:17:21 +00:00
|
|
|
Statement.cpp
|
2009-06-20 18:17:48 +00:00
|
|
|
SymbolInfo.cpp
|
2009-07-07 20:47:39 +00:00
|
|
|
UserBreakpoint.cpp
|
2009-06-20 18:17:48 +00:00
|
|
|
Team.cpp
|
2009-06-26 00:39:23 +00:00
|
|
|
TeamMemory.cpp
|
2011-06-10 01:58:39 +00:00
|
|
|
TeamMemoryBlock.cpp
|
2009-06-20 18:17:48 +00:00
|
|
|
Thread.cpp
|
|
|
|
ThreadInfo.cpp
|
2009-07-17 01:54:43 +00:00
|
|
|
Type.cpp
|
2009-07-18 23:52:16 +00:00
|
|
|
TypeComponentPath.cpp
|
2009-07-17 01:54:43 +00:00
|
|
|
Variable.cpp
|
2009-06-20 18:17:48 +00:00
|
|
|
|
2009-07-24 02:35:30 +00:00
|
|
|
# settings
|
|
|
|
BreakpointSetting.cpp
|
|
|
|
TeamSettings.cpp
|
|
|
|
SettingsManager.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
|
|
|
|
|
2009-07-13 20:45:15 +00:00
|
|
|
# source_language
|
|
|
|
CLanguage.cpp
|
|
|
|
CLanguageFamily.cpp
|
|
|
|
CppLanguage.cpp
|
|
|
|
SourceLanguage.cpp
|
|
|
|
SyntaxHighlighter.cpp
|
|
|
|
UnsupportedLanguage.cpp
|
|
|
|
X86AssemblyLanguage.cpp
|
|
|
|
|
2009-06-29 22:38:15 +00:00
|
|
|
# types
|
2009-10-01 09:37:24 +00:00
|
|
|
ArrayIndexPath.cpp
|
2009-06-29 22:38:15 +00:00
|
|
|
TargetAddressRangeList.cpp
|
2009-07-17 01:54:43 +00:00
|
|
|
ValueLocation.cpp
|
2009-06-29 22:38:15 +00:00
|
|
|
|
* 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/gui
|
|
|
|
GraphicalUserInterface.cpp
|
|
|
|
|
|
|
|
# user_interface/gui/model
|
|
|
|
VariablesViewState.cpp
|
|
|
|
VariablesViewStateHistory.cpp
|
|
|
|
|
2011-06-10 01:58:39 +00:00
|
|
|
# user_interface/gui/inspector_window
|
|
|
|
InspectorWindow.cpp
|
|
|
|
MemoryView.cpp
|
|
|
|
|
2010-09-21 15:07:48 +00:00
|
|
|
# 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
|
|
|
|
SettingsMenu.cpp
|
|
|
|
TargetAddressTableColumn.cpp
|
|
|
|
|
|
|
|
# user_interface/gui/value
|
|
|
|
TableCellBoolRenderer.cpp
|
|
|
|
TableCellEnumerationRenderer.cpp
|
|
|
|
TableCellFloatRenderer.cpp
|
|
|
|
TableCellIntegerRenderer.cpp
|
|
|
|
TableCellStringRenderer.cpp
|
|
|
|
TableCellValueRenderer.cpp
|
|
|
|
TableCellValueRendererUtils.cpp
|
|
|
|
|
2009-07-01 22:09:33 +00:00
|
|
|
# util
|
2009-07-24 02:35:30 +00:00
|
|
|
ArchivingUtils.cpp
|
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
|
2009-07-01 22:09:33 +00:00
|
|
|
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
|
|
|
|
|
2010-11-09 01:06:32 +00:00
|
|
|
# value/type_handlers
|
2011-06-21 22:59:54 +00:00
|
|
|
BMessageTypeHandler.cpp
|
2010-11-09 01:06:32 +00:00
|
|
|
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
|
2010-11-09 01:06:32 +00:00
|
|
|
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
|
2011-06-21 22:59:54 +00:00
|
|
|
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
|
2010-11-09 01:06:32 +00:00
|
|
|
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
|
2010-11-09 01:06:32 +00:00
|
|
|
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
|
|
|
|
2009-06-16 21:47:49 +00:00
|
|
|
:
|
2009-06-20 18:45:20 +00:00
|
|
|
<nogrist>Debugger_demangler.o
|
2009-06-21 13:17:21 +00:00
|
|
|
<nogrist>Debugger_disasm_x86.o
|
2009-06-27 22:12:26 +00:00
|
|
|
<nogrist>Debugger_dwarf.o
|
2009-06-16 21:47:49 +00:00
|
|
|
<nogrist>DebugAnalyzer_gui_table.o
|
|
|
|
|
2009-06-21 13:17:21 +00:00
|
|
|
libudis86.a
|
2009-06-16 21:47:49 +00:00
|
|
|
<bin>debug_utils.a
|
|
|
|
libcolumnlistview.a
|
2009-06-19 23:00:25 +00:00
|
|
|
libshared.a
|
2009-06-16 21:47:49 +00:00
|
|
|
|
|
|
|
$(TARGET_LIBSTDC++)
|
2011-06-10 01:58:39 +00:00
|
|
|
be tracker libdebug.so libshared.a libexpression_parser.a libmapm.a
|
2009-06-16 21:47:49 +00:00
|
|
|
|
|
|
|
: Debugger.rdef
|
2009-06-14 12:53:29 +00:00
|
|
|
;
|
2009-06-15 23:11:19 +00:00
|
|
|
|
2009-06-21 13:17:21 +00:00
|
|
|
HaikuSubInclude arch x86 disasm ;
|
2009-06-20 18:45:20 +00:00
|
|
|
HaikuSubInclude demangler ;
|
2009-06-27 22:12:26 +00:00
|
|
|
HaikuSubInclude dwarf ;
|