llvm-project/lldb/source/Target/ThreadPlanTracer.cpp

271 lines
8.1 KiB
C++
Raw Normal View History

//===-- ThreadPlan.cpp ------------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
// C Includes
// C++ Includes
#include <cstring>
// Other libraries and framework includes
// Project includes
#include "lldb/Target/ThreadPlan.h"
#include "lldb/Core/ArchSpec.h"
#include "lldb/Core/DataBufferHeap.h"
#include "lldb/Core/DataExtractor.h"
#include "lldb/Core/Debugger.h"
#include "lldb/Core/Disassembler.h"
#include "lldb/Core/Log.h"
<rdar://problem/11757916> Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
2012-08-30 05:13:06 +08:00
#include "lldb/Core/Module.h"
#include "lldb/Core/State.h"
#include "lldb/Core/StreamFile.h"
#include "lldb/Core/Value.h"
#include "lldb/Symbol/TypeList.h"
#include "lldb/Symbol/TypeSystem.h"
#include "lldb/Target/ABI.h"
#include "lldb/Target/RegisterContext.h"
#include "lldb/Target/Thread.h"
#include "lldb/Target/Process.h"
#include "lldb/Target/SectionLoadList.h"
#include "lldb/Target/Target.h"
using namespace lldb;
using namespace lldb_private;
#pragma mark ThreadPlanTracer
ThreadPlanTracer::ThreadPlanTracer (Thread &thread, lldb::StreamSP &stream_sp) :
m_thread (thread),
m_single_step(true),
m_enabled (false),
m_stream_sp (stream_sp)
{
}
ThreadPlanTracer::ThreadPlanTracer (Thread &thread) :
m_thread (thread),
m_single_step(true),
m_enabled (false),
m_stream_sp ()
{
}
Stream *
ThreadPlanTracer::GetLogStream ()
{
if (m_stream_sp)
return m_stream_sp.get();
else
{
TargetSP target_sp (m_thread.CalculateTarget());
if (target_sp)
return target_sp->GetDebugger().GetOutputFile().get();
}
return nullptr;
}
void
ThreadPlanTracer::Log()
{
SymbolContext sc;
bool show_frame_index = false;
bool show_fullpaths = false;
Stream *stream = GetLogStream();
if (stream)
{
m_thread.GetStackFrameAtIndex(0)->Dump (stream, show_frame_index, show_fullpaths);
stream->Printf("\n");
stream->Flush();
}
}
bool
ThreadPlanTracer::TracerExplainsStop ()
{
if (m_enabled && m_single_step)
{
lldb::StopInfoSP stop_info = m_thread.GetStopInfo();
return (stop_info->GetStopReason() == eStopReasonTrace);
}
else
return false;
}
#pragma mark ThreadPlanAssemblyTracer
ThreadPlanAssemblyTracer::ThreadPlanAssemblyTracer (Thread &thread, lldb::StreamSP &stream_sp) :
ThreadPlanTracer (thread, stream_sp),
m_disassembler_sp (),
m_intptr_type (),
m_register_values ()
{
}
ThreadPlanAssemblyTracer::ThreadPlanAssemblyTracer (Thread &thread) :
ThreadPlanTracer (thread),
m_disassembler_sp (),
m_intptr_type (),
m_register_values ()
{
}
Disassembler *
ThreadPlanAssemblyTracer::GetDisassembler ()
{
if (!m_disassembler_sp)
m_disassembler_sp = Disassembler::FindPlugin(m_thread.GetProcess()->GetTarget().GetArchitecture(), nullptr, nullptr);
return m_disassembler_sp.get();
}
TypeFromUser
ThreadPlanAssemblyTracer::GetIntPointerType()
{
if (!m_intptr_type.IsValid ())
{
TargetSP target_sp (m_thread.CalculateTarget());
if (target_sp)
{
TypeSystem *type_system = target_sp->GetScratchTypeSystemForLanguage(nullptr, eLanguageTypeC);
TypeSystem is now a plugin interface and removed any "ClangASTContext &Class::GetClangASTContext()" functions. This cleans up type systems to be more pluggable. Prior to this we had issues: - Module, SymbolFile, and many others has "ClangASTContext &GetClangASTContext()" functions. All have been switched over to use "TypeSystem *GetTypeSystemForLanguage()" - Cleaned up any places that were using the GetClangASTContext() functions to use TypeSystem - Cleaned up Module so that it no longer has dedicated type system member variables: lldb::ClangASTContextUP m_ast; ///< The Clang AST context for this module. lldb::GoASTContextUP m_go_ast; ///< The Go AST context for this module. Now we have a type system map: typedef std::map<lldb::LanguageType, lldb::TypeSystemSP> TypeSystemMap; TypeSystemMap m_type_system_map; ///< A map of any type systems associated with this module - Many places in code were using ClangASTContext static functions to place with CompilerType objects and add modifiers (const, volatile, restrict) and to make typedefs, L and R value references and more. These have been made into CompilerType functions that are abstract: class CompilerType { ... //---------------------------------------------------------------------- // Return a new CompilerType that is a L value reference to this type if // this type is valid and the type system supports L value references, // else return an invalid type. //---------------------------------------------------------------------- CompilerType GetLValueReferenceType () const; //---------------------------------------------------------------------- // Return a new CompilerType that is a R value reference to this type if // this type is valid and the type system supports R value references, // else return an invalid type. //---------------------------------------------------------------------- CompilerType GetRValueReferenceType () const; //---------------------------------------------------------------------- // Return a new CompilerType adds a const modifier to this type if // this type is valid and the type system supports const modifiers, // else return an invalid type. //---------------------------------------------------------------------- CompilerType AddConstModifier () const; //---------------------------------------------------------------------- // Return a new CompilerType adds a volatile modifier to this type if // this type is valid and the type system supports volatile modifiers, // else return an invalid type. //---------------------------------------------------------------------- CompilerType AddVolatileModifier () const; //---------------------------------------------------------------------- // Return a new CompilerType adds a restrict modifier to this type if // this type is valid and the type system supports restrict modifiers, // else return an invalid type. //---------------------------------------------------------------------- CompilerType AddRestrictModifier () const; //---------------------------------------------------------------------- // Create a typedef to this type using "name" as the name of the typedef // this type is valid and the type system supports typedefs, else return // an invalid type. //---------------------------------------------------------------------- CompilerType CreateTypedef (const char *name, const CompilerDeclContext &decl_ctx) const; }; Other changes include: - Removed "CompilerType TypeSystem::GetIntTypeFromBitSize(...)" and CompilerType TypeSystem::GetFloatTypeFromBitSize(...) and replaced it with "CompilerType TypeSystem::GetBuiltinTypeForEncodingAndBitSize(lldb::Encoding encoding, size_t bit_size);" - Fixed code in Type.h to not request the full type for a type for no good reason, just request the forward type and let the type expand as needed llvm-svn: 247953
2015-09-18 06:23:34 +08:00
if (type_system)
m_intptr_type = TypeFromUser(type_system->GetBuiltinTypeForEncodingAndBitSize(eEncodingUint, target_sp->GetArchitecture().GetAddressByteSize() * 8));
}
}
return m_intptr_type;
}
ThreadPlanAssemblyTracer::~ThreadPlanAssemblyTracer() = default;
Fixed issues with RegisterContext classes and the subclasses. There was an issue with the way the UnwindLLDB was handing out RegisterContexts: it was making shared pointers to register contexts and then handing out just the pointers (which would get put into shared pointers in the thread and stack frame classes) and cause double free issues. MallocScribble helped to find these issues after I did some other cleanup. To help avoid any RegisterContext issue in the future, all code that deals with them now returns shared pointers to the register contexts so we don't end up with multiple deletions. Also now that the RegisterContext class doesn't require a stack frame, we patched a memory leak where a StackFrame object was being created and leaked. Made the RegisterContext class not have a pointer to a StackFrame object as one register context class can be used for N inlined stack frames so there is not a 1 - 1 mapping. Updates the ExecutionContextScope part of the RegisterContext class to never return a stack frame to indicate this when it is asked to recreate the execution context. Now register contexts point to the concrete frame using a concrete frame index. Concrete frames are all of the frames that are actually formed on the stack of a thread. These concrete frames can be turned into one or more user visible frames due to inlining. Each inlined stack frame has the exact same register context (shared via shared pointers) as any parent inlined stack frames all the way up to the concrete frame itself. So now the stack frames and the register contexts should behave much better. llvm-svn: 122976
2011-01-07 06:15:06 +08:00
void
ThreadPlanAssemblyTracer::TracingStarted ()
{
Fixed issues with RegisterContext classes and the subclasses. There was an issue with the way the UnwindLLDB was handing out RegisterContexts: it was making shared pointers to register contexts and then handing out just the pointers (which would get put into shared pointers in the thread and stack frame classes) and cause double free issues. MallocScribble helped to find these issues after I did some other cleanup. To help avoid any RegisterContext issue in the future, all code that deals with them now returns shared pointers to the register contexts so we don't end up with multiple deletions. Also now that the RegisterContext class doesn't require a stack frame, we patched a memory leak where a StackFrame object was being created and leaked. Made the RegisterContext class not have a pointer to a StackFrame object as one register context class can be used for N inlined stack frames so there is not a 1 - 1 mapping. Updates the ExecutionContextScope part of the RegisterContext class to never return a stack frame to indicate this when it is asked to recreate the execution context. Now register contexts point to the concrete frame using a concrete frame index. Concrete frames are all of the frames that are actually formed on the stack of a thread. These concrete frames can be turned into one or more user visible frames due to inlining. Each inlined stack frame has the exact same register context (shared via shared pointers) as any parent inlined stack frames all the way up to the concrete frame itself. So now the stack frames and the register contexts should behave much better. llvm-svn: 122976
2011-01-07 06:15:06 +08:00
RegisterContext *reg_ctx = m_thread.GetRegisterContext().get();
if (m_register_values.empty())
m_register_values.resize (reg_ctx->GetRegisterCount());
}
Fixed issues with RegisterContext classes and the subclasses. There was an issue with the way the UnwindLLDB was handing out RegisterContexts: it was making shared pointers to register contexts and then handing out just the pointers (which would get put into shared pointers in the thread and stack frame classes) and cause double free issues. MallocScribble helped to find these issues after I did some other cleanup. To help avoid any RegisterContext issue in the future, all code that deals with them now returns shared pointers to the register contexts so we don't end up with multiple deletions. Also now that the RegisterContext class doesn't require a stack frame, we patched a memory leak where a StackFrame object was being created and leaked. Made the RegisterContext class not have a pointer to a StackFrame object as one register context class can be used for N inlined stack frames so there is not a 1 - 1 mapping. Updates the ExecutionContextScope part of the RegisterContext class to never return a stack frame to indicate this when it is asked to recreate the execution context. Now register contexts point to the concrete frame using a concrete frame index. Concrete frames are all of the frames that are actually formed on the stack of a thread. These concrete frames can be turned into one or more user visible frames due to inlining. Each inlined stack frame has the exact same register context (shared via shared pointers) as any parent inlined stack frames all the way up to the concrete frame itself. So now the stack frames and the register contexts should behave much better. llvm-svn: 122976
2011-01-07 06:15:06 +08:00
void
ThreadPlanAssemblyTracer::TracingEnded ()
{
m_register_values.clear();
}
Fixed issues with RegisterContext classes and the subclasses. There was an issue with the way the UnwindLLDB was handing out RegisterContexts: it was making shared pointers to register contexts and then handing out just the pointers (which would get put into shared pointers in the thread and stack frame classes) and cause double free issues. MallocScribble helped to find these issues after I did some other cleanup. To help avoid any RegisterContext issue in the future, all code that deals with them now returns shared pointers to the register contexts so we don't end up with multiple deletions. Also now that the RegisterContext class doesn't require a stack frame, we patched a memory leak where a StackFrame object was being created and leaked. Made the RegisterContext class not have a pointer to a StackFrame object as one register context class can be used for N inlined stack frames so there is not a 1 - 1 mapping. Updates the ExecutionContextScope part of the RegisterContext class to never return a stack frame to indicate this when it is asked to recreate the execution context. Now register contexts point to the concrete frame using a concrete frame index. Concrete frames are all of the frames that are actually formed on the stack of a thread. These concrete frames can be turned into one or more user visible frames due to inlining. Each inlined stack frame has the exact same register context (shared via shared pointers) as any parent inlined stack frames all the way up to the concrete frame itself. So now the stack frames and the register contexts should behave much better. llvm-svn: 122976
2011-01-07 06:15:06 +08:00
void
ThreadPlanAssemblyTracer::Log ()
{
Stream *stream = GetLogStream ();
if (!stream)
return;
Fixed issues with RegisterContext classes and the subclasses. There was an issue with the way the UnwindLLDB was handing out RegisterContexts: it was making shared pointers to register contexts and then handing out just the pointers (which would get put into shared pointers in the thread and stack frame classes) and cause double free issues. MallocScribble helped to find these issues after I did some other cleanup. To help avoid any RegisterContext issue in the future, all code that deals with them now returns shared pointers to the register contexts so we don't end up with multiple deletions. Also now that the RegisterContext class doesn't require a stack frame, we patched a memory leak where a StackFrame object was being created and leaked. Made the RegisterContext class not have a pointer to a StackFrame object as one register context class can be used for N inlined stack frames so there is not a 1 - 1 mapping. Updates the ExecutionContextScope part of the RegisterContext class to never return a stack frame to indicate this when it is asked to recreate the execution context. Now register contexts point to the concrete frame using a concrete frame index. Concrete frames are all of the frames that are actually formed on the stack of a thread. These concrete frames can be turned into one or more user visible frames due to inlining. Each inlined stack frame has the exact same register context (shared via shared pointers) as any parent inlined stack frames all the way up to the concrete frame itself. So now the stack frames and the register contexts should behave much better. llvm-svn: 122976
2011-01-07 06:15:06 +08:00
RegisterContext *reg_ctx = m_thread.GetRegisterContext().get();
lldb::addr_t pc = reg_ctx->GetPC();
ProcessSP process_sp (m_thread.GetProcess());
Address pc_addr;
bool addr_valid = false;
uint8_t buffer[16] = {0}; // Must be big enough for any single instruction
addr_valid = process_sp->GetTarget().GetSectionLoadList().ResolveLoadAddress (pc, pc_addr);
pc_addr.Dump(stream, &m_thread, Address::DumpStyleResolvedDescription, Address::DumpStyleModuleWithFileAddress);
stream->PutCString (" ");
Disassembler *disassembler = GetDisassembler();
if (disassembler)
{
Error err;
process_sp->ReadMemory(pc, buffer, sizeof(buffer), err);
if (err.Success())
{
DataExtractor extractor(buffer, sizeof(buffer),
process_sp->GetByteOrder(),
process_sp->GetAddressByteSize());
bool data_from_file = false;
if (addr_valid)
disassembler->DecodeInstructions (pc_addr, extractor, 0, 1, false, data_from_file);
else
disassembler->DecodeInstructions (Address (pc), extractor, 0, 1, false, data_from_file);
InstructionList &instruction_list = disassembler->GetInstructionList();
Added the ability to get the min and max instruction byte size for an architecture into ArchSpec: uint32_t ArchSpec::GetMinimumOpcodeByteSize() const; uint32_t ArchSpec::GetMaximumOpcodeByteSize() const; Added an AddressClass to the Instruction class in Disassembler.h. This allows decoded instructions to know know if they are code, code with alternate ISA (thumb), or even data which can be mixed into code. The instruction does have an address, but it is a good idea to cache this value so we don't have to look it up more than once. Fixed an issue in Opcode::SetOpcodeBytes() where the length wasn't getting set. Changed: bool SymbolContextList::AppendIfUnique (const SymbolContext& sc); To: bool SymbolContextList::AppendIfUnique (const SymbolContext& sc, bool merge_symbol_into_function); This function was typically being used when looking up functions and symbols. Now if you lookup a function, then find the symbol, they can be merged into the same symbol context and not cause multiple symbol contexts to appear in a symbol context list that describes the same function. Fixed the SymbolContext not equal operator which was causing mixed mode disassembly to not work ("disassembler --mixed --name main"). Modified the disassembler classes to know about the fact we know, for a given architecture, what the min and max opcode byte sizes are. The InstructionList class was modified to return the max opcode byte size for all of the instructions in its list. These two fixes means when disassemble a list of instructions and dump them and show the opcode bytes, we can format the output more intelligently when showing opcode bytes. This affects any architectures that have varying opcode byte sizes (x86_64 and i386). Knowing the max opcode byte size also helps us to be able to disassemble N instructions without having to re-read data if we didn't read enough bytes. Added the ability to set the architecture for the disassemble command. This means you can easily cross disassemble data for any supported architecture. I also added the ability to specify "thumb" as an architecture so that we can force disassembly into thumb mode when needed. In GDB this was done using a hack of specifying an odd address when disassembling. I don't want to repeat this hack in LLDB, so the auto detection between ARM and thumb is failing, just specify thumb when disassembling: (lldb) disassemble --arch thumb --name main You can also have data in say an x86_64 file executable and disassemble data as any other supported architecture: % lldb a.out Current executable set to 'a.out' (x86_64). (lldb) b main (lldb) run (lldb) disassemble --arch thumb --count 2 --start-address 0x0000000100001080 --bytes 0x100001080: 0xb580 push {r7, lr} 0x100001082: 0xaf00 add r7, sp, #0 Fixed Target::ReadMemory(...) to be able to deal with Address argument object that isn't section offset. When an address object was supplied that was out on the heap or stack, target read memory would fail. Disassembly uses Target::ReadMemory(...), and the example above where we disassembler thumb opcodes in an x86 binary was failing do to this bug. llvm-svn: 128347
2011-03-27 03:14:58 +08:00
const uint32_t max_opcode_byte_size = instruction_list.GetMaxOpcocdeByteSize();
if (instruction_list.GetSize())
{
const bool show_bytes = true;
const bool show_address = true;
Instruction *instruction = instruction_list.GetInstructionAtIndex(0).get();
Get rid of Debugger::FormatPrompt() and replace it with the new FormatEntity class. Why? Debugger::FormatPrompt() would run through the format prompt every time and parse it and emit it piece by piece. It also did formatting differently depending on which key/value pair it was parsing. The new code improves on this with the following features: 1 - Allow format strings to be parsed into a FormatEntity::Entry which can contain multiple child FormatEntity::Entry objects. This FormatEntity::Entry is a parsed version of what was previously always done in Debugger::FormatPrompt() so it is more efficient to emit formatted strings using the new parsed FormatEntity::Entry. 2 - Allows errors in format strings to be shown immediately when setting the settings (frame-format, thread-format, disassembly-format 3 - Allows auto completion by implementing a new OptionValueFormatEntity and switching frame-format, thread-format, and disassembly-format settings over to using it. 4 - The FormatEntity::Entry for each of the frame-format, thread-format, disassembly-format settings only replaces the old one if the format parses correctly 5 - Combines all consecutive string values together for efficient output. This means all "${ansi.*}" keys and all desensitized characters like "\n" "\t" "\0721" "\x23" will get combined with their previous strings 6 - ${*.script:} (like "${var.script:mymodule.my_var_function}") have all been switched over to use ${script.*:} "${script.var:mymodule.my_var_function}") to make the format easier to parse as I don't believe anyone was using these format string power user features. 7 - All key values pairs are defined in simple C arrays of entries so it is much easier to add new entries. These changes pave the way for subsequent modifications where we can modify formats to do more (like control the width of value strings can do more and add more functionality more easily like string formatting to control the width, printf formats and more). llvm-svn: 228207
2015-02-05 06:00:53 +08:00
const FormatEntity::Entry *disassemble_format = m_thread.GetProcess()->GetTarget().GetDebugger().GetDisassemblyFormat();
instruction->Dump(stream,
max_opcode_byte_size,
show_address,
show_bytes,
nullptr,
nullptr,
nullptr,
disassemble_format,
0);
}
}
}
const ABI *abi = process_sp->GetABI().get();
TypeFromUser intptr_type = GetIntPointerType();
if (abi && intptr_type.IsValid())
{
ValueList value_list;
const int num_args = 1;
for (int arg_index = 0; arg_index < num_args; ++arg_index)
{
Value value;
value.SetValueType (Value::eValueTypeScalar);
// value.SetContext (Value::eContextTypeClangType, intptr_type.GetOpaqueQualType());
Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
2015-08-25 07:46:31 +08:00
value.SetCompilerType (intptr_type);
value_list.PushValue (value);
}
if (abi->GetArgumentValues (m_thread, value_list))
{
for (int arg_index = 0; arg_index < num_args; ++arg_index)
{
stream->Printf("\n\targ[%d]=%llx", arg_index, value_list.GetValueAtIndex(arg_index)->GetScalar().ULongLong());
if (arg_index + 1 < num_args)
stream->PutCString (", ");
}
}
}
RegisterValue reg_value;
for (uint32_t reg_num = 0, num_registers = reg_ctx->GetRegisterCount();
reg_num < num_registers;
++reg_num)
{
const RegisterInfo *reg_info = reg_ctx->GetRegisterInfoAtIndex(reg_num);
if (reg_ctx->ReadRegister (reg_info, reg_value))
{
assert (reg_num < m_register_values.size());
if (m_register_values[reg_num].GetType() == RegisterValue::eTypeInvalid ||
reg_value != m_register_values[reg_num])
{
if (reg_value.GetType() != RegisterValue::eTypeInvalid)
{
stream->PutCString ("\n\t");
reg_value.Dump(stream, reg_info, true, false, eFormatDefault);
}
}
m_register_values[reg_num] = reg_value;
}
}
stream->EOL();
stream->Flush();
}