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

1595 lines
52 KiB
C++
Raw Normal View History

//===-- Target.cpp ----------------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "lldb/Target/Target.h"
// C Includes
// C++ Includes
// Other libraries and framework includes
// Project includes
#include "lldb/Breakpoint/BreakpointResolver.h"
#include "lldb/Breakpoint/BreakpointResolverAddress.h"
#include "lldb/Breakpoint/BreakpointResolverFileLine.h"
#include "lldb/Breakpoint/BreakpointResolverName.h"
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
#include "lldb/Core/Debugger.h"
#include "lldb/Core/Event.h"
#include "lldb/Core/Log.h"
#include "lldb/Core/StreamString.h"
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
#include "lldb/Core/Timer.h"
#include "lldb/Core/ValueObject.h"
#include "lldb/Host/Host.h"
#include "lldb/Interpreter/CommandInterpreter.h"
#include "lldb/Interpreter/CommandReturnObject.h"
#include "lldb/lldb-private-log.h"
#include "lldb/Symbol/ObjectFile.h"
#include "lldb/Target/Process.h"
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
#include "lldb/Target/StackFrame.h"
#include "lldb/Target/Thread.h"
#include "lldb/Target/ThreadSpec.h"
using namespace lldb;
using namespace lldb_private;
//----------------------------------------------------------------------
// Target constructor
//----------------------------------------------------------------------
Target::Target(Debugger &debugger) :
Broadcaster("lldb.target"),
TargetInstanceSettings (*GetSettingsController()),
m_debugger (debugger),
m_mutex (Mutex::eMutexTypeRecursive),
m_images(),
m_section_load_list (),
m_breakpoint_list (false),
m_internal_breakpoint_list (true),
m_process_sp(),
m_search_filter_sp(),
m_image_search_paths (ImageSearchPathsChanged, this),
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
m_scratch_ast_context_ap (NULL),
m_persistent_variables (),
m_stop_hook_next_id(0)
{
SetEventName (eBroadcastBitBreakpointChanged, "breakpoint-changed");
SetEventName (eBroadcastBitModulesLoaded, "modules-loaded");
SetEventName (eBroadcastBitModulesUnloaded, "modules-unloaded");
LogSP log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_OBJECT));
if (log)
log->Printf ("%p Target::Target()", this);
}
//----------------------------------------------------------------------
// Destructor
//----------------------------------------------------------------------
Target::~Target()
{
LogSP log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_OBJECT));
if (log)
log->Printf ("%p Target::~Target()", this);
DeleteCurrentProcess ();
}
void
Target::Dump (Stream *s, lldb::DescriptionLevel description_level)
{
// s->Printf("%.*p: ", (int)sizeof(void*) * 2, this);
if (description_level != lldb::eDescriptionLevelBrief)
{
s->Indent();
s->PutCString("Target\n");
s->IndentMore();
m_images.Dump(s);
m_breakpoint_list.Dump(s);
m_internal_breakpoint_list.Dump(s);
s->IndentLess();
}
else
{
2010-10-30 12:51:46 +08:00
s->PutCString (GetExecutableModule()->GetFileSpec().GetFilename().GetCString());
}
}
void
Target::DeleteCurrentProcess ()
{
if (m_process_sp.get())
{
m_section_load_list.Clear();
if (m_process_sp->IsAlive())
m_process_sp->Destroy();
m_process_sp->Finalize();
// Do any cleanup of the target we need to do between process instances.
// NB It is better to do this before destroying the process in case the
// clean up needs some help from the process.
m_breakpoint_list.ClearAllBreakpointSites();
m_internal_breakpoint_list.ClearAllBreakpointSites();
m_process_sp.reset();
}
}
const lldb::ProcessSP &
Target::CreateProcess (Listener &listener, const char *plugin_name)
{
DeleteCurrentProcess ();
m_process_sp.reset(Process::FindPlugin(*this, plugin_name, listener));
return m_process_sp;
}
const lldb::ProcessSP &
Target::GetProcessSP () const
{
return m_process_sp;
}
lldb::TargetSP
Target::GetSP()
{
return m_debugger.GetTargetList().GetTargetSP(this);
}
BreakpointList &
Target::GetBreakpointList(bool internal)
{
if (internal)
return m_internal_breakpoint_list;
else
return m_breakpoint_list;
}
const BreakpointList &
Target::GetBreakpointList(bool internal) const
{
if (internal)
return m_internal_breakpoint_list;
else
return m_breakpoint_list;
}
BreakpointSP
Target::GetBreakpointByID (break_id_t break_id)
{
BreakpointSP bp_sp;
if (LLDB_BREAK_ID_IS_INTERNAL (break_id))
bp_sp = m_internal_breakpoint_list.FindBreakpointByID (break_id);
else
bp_sp = m_breakpoint_list.FindBreakpointByID (break_id);
return bp_sp;
}
BreakpointSP
Target::CreateBreakpoint (const FileSpec *containingModule, const FileSpec &file, uint32_t line_no, bool check_inlines, bool internal)
{
SearchFilterSP filter_sp(GetSearchFilterForModule (containingModule));
BreakpointResolverSP resolver_sp(new BreakpointResolverFileLine (NULL, file, line_no, check_inlines));
return CreateBreakpoint (filter_sp, resolver_sp, internal);
}
BreakpointSP
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
Target::CreateBreakpoint (lldb::addr_t addr, bool internal)
{
Address so_addr;
// Attempt to resolve our load address if possible, though it is ok if
// it doesn't resolve to section/offset.
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
// Try and resolve as a load address if possible
m_section_load_list.ResolveLoadAddress(addr, so_addr);
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
if (!so_addr.IsValid())
{
// The address didn't resolve, so just set this as an absolute address
so_addr.SetOffset (addr);
}
BreakpointSP bp_sp (CreateBreakpoint(so_addr, internal));
return bp_sp;
}
BreakpointSP
Target::CreateBreakpoint (Address &addr, bool internal)
{
TargetSP target_sp = this->GetSP();
SearchFilterSP filter_sp(new SearchFilter (target_sp));
BreakpointResolverSP resolver_sp (new BreakpointResolverAddress (NULL, addr));
return CreateBreakpoint (filter_sp, resolver_sp, internal);
}
BreakpointSP
Added function name types to allow us to set breakpoints by name more intelligently. The four name types we currently have are: eFunctionNameTypeFull = (1 << 1), // The function name. // For C this is the same as just the name of the function // For C++ this is the demangled version of the mangled name. // For ObjC this is the full function signature with the + or // - and the square brackets and the class and selector eFunctionNameTypeBase = (1 << 2), // The function name only, no namespaces or arguments and no class // methods or selectors will be searched. eFunctionNameTypeMethod = (1 << 3), // Find function by method name (C++) with no namespace or arguments eFunctionNameTypeSelector = (1 << 4) // Find function by selector name (ObjC) names this allows much more flexibility when setting breakoints: (lldb) breakpoint set --name main --basename (lldb) breakpoint set --name main --fullname (lldb) breakpoint set --name main --method (lldb) breakpoint set --name main --selector The default: (lldb) breakpoint set --name main will inspect the name "main" and look for any parens, or if the name starts with "-[" or "+[" and if any are found then a full name search will happen. Else a basename search will be the default. Fixed some command option structures so not all options are required when they shouldn't be. Cleaned up the breakpoint output summary. Made the "image lookup --address <addr>" output much more verbose so it shows all the important symbol context results. Added a GetDescription method to many of the SymbolContext objects for the more verbose output. llvm-svn: 107075
2010-06-29 05:30:43 +08:00
Target::CreateBreakpoint (FileSpec *containingModule, const char *func_name, uint32_t func_name_type_mask, bool internal)
{
Added function name types to allow us to set breakpoints by name more intelligently. The four name types we currently have are: eFunctionNameTypeFull = (1 << 1), // The function name. // For C this is the same as just the name of the function // For C++ this is the demangled version of the mangled name. // For ObjC this is the full function signature with the + or // - and the square brackets and the class and selector eFunctionNameTypeBase = (1 << 2), // The function name only, no namespaces or arguments and no class // methods or selectors will be searched. eFunctionNameTypeMethod = (1 << 3), // Find function by method name (C++) with no namespace or arguments eFunctionNameTypeSelector = (1 << 4) // Find function by selector name (ObjC) names this allows much more flexibility when setting breakoints: (lldb) breakpoint set --name main --basename (lldb) breakpoint set --name main --fullname (lldb) breakpoint set --name main --method (lldb) breakpoint set --name main --selector The default: (lldb) breakpoint set --name main will inspect the name "main" and look for any parens, or if the name starts with "-[" or "+[" and if any are found then a full name search will happen. Else a basename search will be the default. Fixed some command option structures so not all options are required when they shouldn't be. Cleaned up the breakpoint output summary. Made the "image lookup --address <addr>" output much more verbose so it shows all the important symbol context results. Added a GetDescription method to many of the SymbolContext objects for the more verbose output. llvm-svn: 107075
2010-06-29 05:30:43 +08:00
BreakpointSP bp_sp;
if (func_name)
{
SearchFilterSP filter_sp(GetSearchFilterForModule (containingModule));
BreakpointResolverSP resolver_sp (new BreakpointResolverName (NULL, func_name, func_name_type_mask, Breakpoint::Exact));
bp_sp = CreateBreakpoint (filter_sp, resolver_sp, internal);
}
return bp_sp;
}
SearchFilterSP
Target::GetSearchFilterForModule (const FileSpec *containingModule)
{
SearchFilterSP filter_sp;
lldb::TargetSP target_sp = this->GetSP();
if (containingModule != NULL)
{
// TODO: We should look into sharing module based search filters
// across many breakpoints like we do for the simple target based one
filter_sp.reset (new SearchFilterByModule (target_sp, *containingModule));
}
else
{
if (m_search_filter_sp.get() == NULL)
m_search_filter_sp.reset (new SearchFilter (target_sp));
filter_sp = m_search_filter_sp;
}
return filter_sp;
}
BreakpointSP
Target::CreateBreakpoint (FileSpec *containingModule, RegularExpression &func_regex, bool internal)
{
SearchFilterSP filter_sp(GetSearchFilterForModule (containingModule));
BreakpointResolverSP resolver_sp(new BreakpointResolverName (NULL, func_regex));
return CreateBreakpoint (filter_sp, resolver_sp, internal);
}
BreakpointSP
Target::CreateBreakpoint (SearchFilterSP &filter_sp, BreakpointResolverSP &resolver_sp, bool internal)
{
BreakpointSP bp_sp;
if (filter_sp && resolver_sp)
{
bp_sp.reset(new Breakpoint (*this, filter_sp, resolver_sp));
resolver_sp->SetBreakpoint (bp_sp.get());
if (internal)
m_internal_breakpoint_list.Add (bp_sp, false);
else
m_breakpoint_list.Add (bp_sp, true);
LogSP log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_BREAKPOINTS));
if (log)
{
StreamString s;
bp_sp->GetDescription(&s, lldb::eDescriptionLevelVerbose);
log->Printf ("Target::%s (internal = %s) => break_id = %s\n", __FUNCTION__, internal ? "yes" : "no", s.GetData());
}
bp_sp->ResolveBreakpoint();
}
if (!internal && bp_sp)
{
m_last_created_breakpoint = bp_sp;
}
return bp_sp;
}
void
Target::RemoveAllBreakpoints (bool internal_also)
{
LogSP log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_BREAKPOINTS));
if (log)
log->Printf ("Target::%s (internal_also = %s)\n", __FUNCTION__, internal_also ? "yes" : "no");
m_breakpoint_list.RemoveAll (true);
if (internal_also)
m_internal_breakpoint_list.RemoveAll (false);
m_last_created_breakpoint.reset();
}
void
Target::DisableAllBreakpoints (bool internal_also)
{
LogSP log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_BREAKPOINTS));
if (log)
log->Printf ("Target::%s (internal_also = %s)\n", __FUNCTION__, internal_also ? "yes" : "no");
m_breakpoint_list.SetEnabledAll (false);
if (internal_also)
m_internal_breakpoint_list.SetEnabledAll (false);
}
void
Target::EnableAllBreakpoints (bool internal_also)
{
LogSP log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_BREAKPOINTS));
if (log)
log->Printf ("Target::%s (internal_also = %s)\n", __FUNCTION__, internal_also ? "yes" : "no");
m_breakpoint_list.SetEnabledAll (true);
if (internal_also)
m_internal_breakpoint_list.SetEnabledAll (true);
}
bool
Target::RemoveBreakpointByID (break_id_t break_id)
{
LogSP log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_BREAKPOINTS));
if (log)
log->Printf ("Target::%s (break_id = %i, internal = %s)\n", __FUNCTION__, break_id, LLDB_BREAK_ID_IS_INTERNAL (break_id) ? "yes" : "no");
if (DisableBreakpointByID (break_id))
{
if (LLDB_BREAK_ID_IS_INTERNAL (break_id))
m_internal_breakpoint_list.Remove(break_id, false);
else
{
if (m_last_created_breakpoint)
{
if (m_last_created_breakpoint->GetID() == break_id)
m_last_created_breakpoint.reset();
}
m_breakpoint_list.Remove(break_id, true);
}
return true;
}
return false;
}
bool
Target::DisableBreakpointByID (break_id_t break_id)
{
LogSP log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_BREAKPOINTS));
if (log)
log->Printf ("Target::%s (break_id = %i, internal = %s)\n", __FUNCTION__, break_id, LLDB_BREAK_ID_IS_INTERNAL (break_id) ? "yes" : "no");
BreakpointSP bp_sp;
if (LLDB_BREAK_ID_IS_INTERNAL (break_id))
bp_sp = m_internal_breakpoint_list.FindBreakpointByID (break_id);
else
bp_sp = m_breakpoint_list.FindBreakpointByID (break_id);
if (bp_sp)
{
bp_sp->SetEnabled (false);
return true;
}
return false;
}
bool
Target::EnableBreakpointByID (break_id_t break_id)
{
LogSP log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_BREAKPOINTS));
if (log)
log->Printf ("Target::%s (break_id = %i, internal = %s)\n",
__FUNCTION__,
break_id,
LLDB_BREAK_ID_IS_INTERNAL (break_id) ? "yes" : "no");
BreakpointSP bp_sp;
if (LLDB_BREAK_ID_IS_INTERNAL (break_id))
bp_sp = m_internal_breakpoint_list.FindBreakpointByID (break_id);
else
bp_sp = m_breakpoint_list.FindBreakpointByID (break_id);
if (bp_sp)
{
bp_sp->SetEnabled (true);
return true;
}
return false;
}
ModuleSP
Target::GetExecutableModule ()
{
ModuleSP executable_sp;
if (m_images.GetSize() > 0)
executable_sp = m_images.GetModuleAtIndex(0);
return executable_sp;
}
void
Target::SetExecutableModule (ModuleSP& executable_sp, bool get_dependent_files)
{
m_images.Clear();
m_scratch_ast_context_ap.reset();
if (executable_sp.get())
{
Timer scoped_timer (__PRETTY_FUNCTION__,
"Target::SetExecutableModule (executable = '%s/%s')",
executable_sp->GetFileSpec().GetDirectory().AsCString(),
executable_sp->GetFileSpec().GetFilename().AsCString());
m_images.Append(executable_sp); // The first image is our exectuable file
ArchSpec exe_arch = executable_sp->GetArchitecture();
// If we haven't set an architecture yet, reset our architecture based on what we found in the executable module.
if (!m_arch_spec.IsValid())
m_arch_spec = exe_arch;
FileSpecList dependent_files;
LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provide an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
2011-03-09 06:40:15 +08:00
ObjectFile *executable_objfile = executable_sp->GetObjectFile();
assert (executable_objfile);
// TODO: remote assertion above after verifying that it doesn't fire off
// after the platform changes. The platform is what should be selecting
// the right slice of an executable file, and it also should be the one
// to resolve any executables in their bundles.
// if (executable_objfile == NULL)
// {
//
// FileSpec bundle_executable(executable_sp->GetFileSpec());
// if (Host::ResolveExecutableInBundle (bundle_executable))
// {
// ModuleSP bundle_exe_module_sp(GetSharedModule(bundle_executable,
// exe_arch));
// SetExecutableModule (bundle_exe_module_sp, get_dependent_files);
// if (bundle_exe_module_sp->GetObjectFile() != NULL)
// executable_sp = bundle_exe_module_sp;
// return;
// }
// }
if (executable_objfile)
{
executable_objfile->GetDependentModules(dependent_files);
for (uint32_t i=0; i<dependent_files.GetSize(); i++)
{
ModuleSP image_module_sp(GetSharedModule(dependent_files.GetFileSpecPointerAtIndex(i),
exe_arch));
if (image_module_sp.get())
{
//image_module_sp->Dump(&s);// REMOVE THIS, DEBUG ONLY
ObjectFile *objfile = image_module_sp->GetObjectFile();
if (objfile)
objfile->GetDependentModules(dependent_files);
}
}
}
// Now see if we know the target triple, and if so, create our scratch AST context:
if (m_arch_spec.IsValid())
{
m_scratch_ast_context_ap.reset (new ClangASTContext(m_arch_spec.GetTriple().str().c_str()));
}
}
UpdateInstanceName();
}
bool
Target::SetArchitecture (const ArchSpec &arch_spec)
{
if (m_arch_spec == arch_spec)
{
// If we're setting the architecture to our current architecture, we
// don't need to do anything.
return true;
}
else if (!m_arch_spec.IsValid())
{
// If we haven't got a valid arch spec, then we just need to set it.
m_arch_spec = arch_spec;
return true;
}
else
{
// If we have an executable file, try to reset the executable to the desired architecture
m_arch_spec = arch_spec;
ModuleSP executable_sp = GetExecutableModule ();
m_images.Clear();
m_scratch_ast_context_ap.reset();
// Need to do something about unsetting breakpoints.
if (executable_sp)
{
FileSpec exec_file_spec = executable_sp->GetFileSpec();
Error error = ModuleList::GetSharedModule(exec_file_spec,
arch_spec,
NULL,
NULL,
0,
executable_sp,
NULL,
NULL);
if (!error.Fail() && executable_sp)
{
SetExecutableModule (executable_sp, true);
return true;
}
else
{
return false;
}
}
else
{
return false;
}
}
}
void
Target::ModuleAdded (ModuleSP &module_sp)
{
// A module is being added to this target for the first time
ModuleList module_list;
module_list.Append(module_sp);
ModulesDidLoad (module_list);
}
void
Target::ModuleUpdated (ModuleSP &old_module_sp, ModuleSP &new_module_sp)
{
// A module is being added to this target for the first time
ModuleList module_list;
module_list.Append (old_module_sp);
ModulesDidUnload (module_list);
module_list.Clear ();
module_list.Append (new_module_sp);
ModulesDidLoad (module_list);
}
void
Target::ModulesDidLoad (ModuleList &module_list)
{
m_breakpoint_list.UpdateBreakpoints (module_list, true);
// TODO: make event data that packages up the module_list
BroadcastEvent (eBroadcastBitModulesLoaded, NULL);
}
void
Target::ModulesDidUnload (ModuleList &module_list)
{
m_breakpoint_list.UpdateBreakpoints (module_list, false);
// Remove the images from the target image list
m_images.Remove(module_list);
// TODO: make event data that packages up the module_list
BroadcastEvent (eBroadcastBitModulesUnloaded, NULL);
}
size_t
Target::ReadMemoryFromFileCache (const Address& addr, void *dst, size_t dst_len, Error &error)
{
const Section *section = addr.GetSection();
if (section && section->GetModule())
{
ObjectFile *objfile = section->GetModule()->GetObjectFile();
if (objfile)
{
size_t bytes_read = section->ReadSectionDataFromObjectFile (objfile,
addr.GetOffset(),
dst,
dst_len);
if (bytes_read > 0)
return bytes_read;
else
error.SetErrorStringWithFormat("error reading data from section %s", section->GetName().GetCString());
}
else
{
error.SetErrorString("address isn't from a object file");
}
}
else
{
error.SetErrorString("address doesn't contain a section that points to a section in a object file");
}
return 0;
}
size_t
Target::ReadMemory (const Address& addr, bool prefer_file_cache, void *dst, size_t dst_len, Error &error)
{
error.Clear();
bool process_is_valid = m_process_sp && m_process_sp->IsAlive();
size_t bytes_read = 0;
Address resolved_addr(addr);
if (!resolved_addr.IsSectionOffset())
{
if (process_is_valid)
{
m_section_load_list.ResolveLoadAddress (addr.GetOffset(), resolved_addr);
}
else
{
m_images.ResolveFileAddress(addr.GetOffset(), resolved_addr);
}
}
if (prefer_file_cache)
{
bytes_read = ReadMemoryFromFileCache (resolved_addr, dst, dst_len, error);
if (bytes_read > 0)
return bytes_read;
}
if (process_is_valid)
{
lldb::addr_t load_addr = resolved_addr.GetLoadAddress (this);
if (load_addr == LLDB_INVALID_ADDRESS)
{
if (resolved_addr.GetModule() && resolved_addr.GetModule()->GetFileSpec())
error.SetErrorStringWithFormat("%s[0x%llx] can't be resolved, %s in not currently loaded.\n",
resolved_addr.GetModule()->GetFileSpec().GetFilename().AsCString(),
resolved_addr.GetFileAddress());
else
error.SetErrorStringWithFormat("0x%llx can't be resolved.\n", resolved_addr.GetFileAddress());
}
else
{
bytes_read = m_process_sp->ReadMemory(load_addr, dst, dst_len, error);
if (bytes_read != dst_len)
{
if (error.Success())
{
if (bytes_read == 0)
error.SetErrorStringWithFormat("Read memory from 0x%llx failed.\n", load_addr);
else
error.SetErrorStringWithFormat("Only %zu of %zu bytes were read from memory at 0x%llx.\n", bytes_read, dst_len, load_addr);
}
}
if (bytes_read)
return bytes_read;
// If the address is not section offset we have an address that
// doesn't resolve to any address in any currently loaded shared
// libaries and we failed to read memory so there isn't anything
// more we can do. If it is section offset, we might be able to
// read cached memory from the object file.
if (!resolved_addr.IsSectionOffset())
return 0;
}
}
if (!prefer_file_cache)
{
// If we didn't already try and read from the object file cache, then
// try it after failing to read from the process.
return ReadMemoryFromFileCache (resolved_addr, dst, dst_len, error);
}
return 0;
}
ModuleSP
Target::GetSharedModule
(
const FileSpec& file_spec,
const ArchSpec& arch,
const lldb_private::UUID *uuid_ptr,
const ConstString *object_name,
off_t object_offset,
Error *error_ptr
)
{
// Don't pass in the UUID so we can tell if we have a stale value in our list
ModuleSP old_module_sp; // This will get filled in if we have a new version of the library
bool did_create_module = false;
ModuleSP module_sp;
// If there are image search path entries, try to use them first to acquire a suitable image.
Error error;
if (m_image_search_paths.GetSize())
{
FileSpec transformed_spec;
if (m_image_search_paths.RemapPath (file_spec.GetDirectory(), transformed_spec.GetDirectory()))
{
transformed_spec.GetFilename() = file_spec.GetFilename();
error = ModuleList::GetSharedModule (transformed_spec, arch, uuid_ptr, object_name, object_offset, module_sp, &old_module_sp, &did_create_module);
}
}
// If a module hasn't been found yet, use the unmodified path.
if (!module_sp)
{
error = (ModuleList::GetSharedModule (file_spec, arch, uuid_ptr, object_name, object_offset, module_sp, &old_module_sp, &did_create_module));
}
if (module_sp)
{
m_images.Append (module_sp);
if (did_create_module)
{
if (old_module_sp && m_images.GetIndexForModule (old_module_sp.get()) != LLDB_INVALID_INDEX32)
ModuleUpdated(old_module_sp, module_sp);
else
ModuleAdded(module_sp);
}
}
if (error_ptr)
*error_ptr = error;
return module_sp;
}
Target *
Target::CalculateTarget ()
{
return this;
}
Process *
Target::CalculateProcess ()
{
return NULL;
}
Thread *
Target::CalculateThread ()
{
return NULL;
}
StackFrame *
Target::CalculateStackFrame ()
{
return NULL;
}
void
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
Target::CalculateExecutionContext (ExecutionContext &exe_ctx)
{
exe_ctx.target = this;
exe_ctx.process = NULL; // Do NOT fill in process...
exe_ctx.thread = NULL;
exe_ctx.frame = NULL;
}
PathMappingList &
Target::GetImageSearchPathList ()
{
return m_image_search_paths;
}
void
Target::ImageSearchPathsChanged
(
const PathMappingList &path_list,
void *baton
)
{
Target *target = (Target *)baton;
if (target->m_images.GetSize() > 1)
{
ModuleSP exe_module_sp (target->GetExecutableModule());
if (exe_module_sp)
{
target->m_images.Clear();
target->SetExecutableModule (exe_module_sp, true);
}
}
}
ClangASTContext *
Target::GetScratchClangASTContext()
{
return m_scratch_ast_context_ap.get();
}
void
Target::SettingsInitialize ()
{
UserSettingsControllerSP &usc = GetSettingsController();
usc.reset (new SettingsController);
UserSettingsController::InitializeSettingsController (usc,
SettingsController::global_settings_table,
SettingsController::instance_settings_table);
// Now call SettingsInitialize() on each 'child' setting of Target
Process::SettingsInitialize ();
}
void
Target::SettingsTerminate ()
{
// Must call SettingsTerminate() on each settings 'child' of Target, before terminating Target's Settings.
Process::SettingsTerminate ();
// Now terminate Target Settings.
UserSettingsControllerSP &usc = GetSettingsController();
UserSettingsController::FinalizeSettingsController (usc);
usc.reset();
}
UserSettingsControllerSP &
Target::GetSettingsController ()
{
static UserSettingsControllerSP g_settings_controller;
return g_settings_controller;
}
ArchSpec
Target::GetDefaultArchitecture ()
{
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
lldb::UserSettingsControllerSP settings_controller_sp (GetSettingsController());
if (settings_controller_sp)
return static_cast<Target::SettingsController *>(settings_controller_sp.get())->GetArchitecture ();
return ArchSpec();
}
void
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
Target::SetDefaultArchitecture (const ArchSpec& arch)
{
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
lldb::UserSettingsControllerSP settings_controller_sp (GetSettingsController());
if (settings_controller_sp)
static_cast<Target::SettingsController *>(settings_controller_sp.get())->GetArchitecture () = arch;
}
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
Target *
Target::GetTargetFromContexts (const ExecutionContext *exe_ctx_ptr, const SymbolContext *sc_ptr)
{
// The target can either exist in the "process" of ExecutionContext, or in
// the "target_sp" member of SymbolContext. This accessor helper function
// will get the target from one of these locations.
Target *target = NULL;
if (sc_ptr != NULL)
target = sc_ptr->target_sp.get();
if (target == NULL)
{
if (exe_ctx_ptr != NULL && exe_ctx_ptr->process != NULL)
target = &exe_ctx_ptr->process->GetTarget();
}
return target;
}
void
Target::UpdateInstanceName ()
{
StreamString sstr;
ModuleSP module_sp = GetExecutableModule();
if (module_sp)
{
sstr.Printf ("%s_%s",
module_sp->GetFileSpec().GetFilename().AsCString(),
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
module_sp->GetArchitecture().GetArchitectureName());
GetSettingsController()->RenameInstanceSettings (GetInstanceName().AsCString(),
sstr.GetData());
}
}
const char *
Target::GetExpressionPrefixContentsAsCString ()
{
return m_expr_prefix_contents.c_str();
}
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
ExecutionResults
Target::EvaluateExpression
(
const char *expr_cstr,
StackFrame *frame,
bool unwind_on_error,
bool keep_in_memory,
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
lldb::ValueObjectSP &result_valobj_sp
)
{
ExecutionResults execution_results = eExecutionSetupError;
result_valobj_sp.reset();
ExecutionContext exe_ctx;
if (frame)
{
frame->CalculateExecutionContext(exe_ctx);
Error error;
const uint32_t expr_path_options = StackFrame::eExpressionPathOptionCheckPtrVsMember |
StackFrame::eExpressionPathOptionsNoFragileObjcIvar;
result_valobj_sp = frame->GetValueForVariableExpressionPath (expr_cstr, expr_path_options, error);
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
}
else if (m_process_sp)
{
m_process_sp->CalculateExecutionContext(exe_ctx);
}
else
{
CalculateExecutionContext(exe_ctx);
}
if (result_valobj_sp)
{
execution_results = eExecutionCompleted;
// We got a result from the frame variable expression path above...
ConstString persistent_variable_name (m_persistent_variables.GetNextPersistentVariableName());
lldb::ValueObjectSP const_valobj_sp;
// Check in case our value is already a constant value
if (result_valobj_sp->GetIsConstant())
{
const_valobj_sp = result_valobj_sp;
const_valobj_sp->SetName (persistent_variable_name);
}
else
const_valobj_sp = result_valobj_sp->CreateConstantValue (exe_ctx.GetBestExecutionContextScope(),
persistent_variable_name);
lldb::ValueObjectSP live_valobj_sp = result_valobj_sp;
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
result_valobj_sp = const_valobj_sp;
ClangExpressionVariableSP clang_expr_variable_sp(m_persistent_variables.CreatePersistentVariable(result_valobj_sp));
assert (clang_expr_variable_sp.get());
// Set flags and live data as appropriate
const Value &result_value = live_valobj_sp->GetValue();
switch (result_value.GetValueType())
{
case Value::eValueTypeHostAddress:
case Value::eValueTypeFileAddress:
// we don't do anything with these for now
break;
case Value::eValueTypeScalar:
clang_expr_variable_sp->m_flags |= ClangExpressionVariable::EVIsLLDBAllocated;
clang_expr_variable_sp->m_flags |= ClangExpressionVariable::EVNeedsAllocation;
break;
case Value::eValueTypeLoadAddress:
clang_expr_variable_sp->m_live_sp = live_valobj_sp;
clang_expr_variable_sp->m_flags |= ClangExpressionVariable::EVIsProgramReference;
break;
}
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
}
else
{
// Make sure we aren't just trying to see the value of a persistent
// variable (something like "$0")
Put more smarts into the RegisterContext base class. Now the base class has a method: void RegisterContext::InvalidateIfNeeded (bool force); Each time this function is called, when "force" is false, it will only call the pure virtual "virtual void RegisterContext::InvalideAllRegisters()" if the register context's stop ID doesn't match that of the process. When the stop ID doesn't match, or "force" is true, the base class will clear its cached registers and the RegisterContext will update its stop ID to match that of the process. This helps make it easier to correctly flush the register context (possibly from multiple locations depending on when and where new registers are availabe) without inadvertently clearing the register cache when it doesn't need to be. Modified the ProcessGDBRemote plug-in to be much more efficient when it comes to: - caching the expedited registers in the stop reply packets (we were ignoring these before and it was causing us to read at least three registers every time we stopped that were already supplied in the stop reply packet). - When a thread has no stop reason, don't keep asking for the thread stopped info. Prior to this fix we would continually send a qThreadStopInfo packet over and over when any thread stop info was requested. We now note the stop ID that the stop info was requested for and avoid multiple requests. Cleaned up some of the expression code to not look for ClangExpressionVariable objects up by name since they are now shared pointers and we can just look for the exact pointer match and avoid possible errors. Fixed an bug in the ValueObject code that would cause children to not be displayed. llvm-svn: 123127
2011-01-10 05:07:35 +08:00
lldb::ClangExpressionVariableSP persistent_var_sp;
// Only check for persistent variables the expression starts with a '$'
if (expr_cstr[0] == '$')
persistent_var_sp = m_persistent_variables.GetVariable (expr_cstr);
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
if (persistent_var_sp)
{
result_valobj_sp = persistent_var_sp->GetValueObject ();
execution_results = eExecutionCompleted;
}
else
{
const char *prefix = GetExpressionPrefixContentsAsCString();
execution_results = ClangUserExpression::Evaluate (exe_ctx,
unwind_on_error,
keep_in_memory,
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
expr_cstr,
prefix,
result_valobj_sp);
}
}
return execution_results;
}
lldb::user_id_t
Target::AddStopHook (Target::StopHookSP &new_hook_sp)
{
lldb::user_id_t new_uid = ++m_stop_hook_next_id;
new_hook_sp.reset (new StopHook(GetSP(), new_uid));
m_stop_hooks[new_uid] = new_hook_sp;
return new_uid;
}
bool
Target::RemoveStopHookByID (lldb::user_id_t user_id)
{
size_t num_removed;
num_removed = m_stop_hooks.erase (user_id);
if (num_removed == 0)
return false;
else
return true;
}
void
Target::RemoveAllStopHooks ()
{
m_stop_hooks.clear();
}
Target::StopHookSP
Target::GetStopHookByID (lldb::user_id_t user_id)
{
StopHookSP found_hook;
StopHookCollection::iterator specified_hook_iter;
specified_hook_iter = m_stop_hooks.find (user_id);
if (specified_hook_iter != m_stop_hooks.end())
found_hook = (*specified_hook_iter).second;
return found_hook;
}
bool
Target::SetStopHookActiveStateByID (lldb::user_id_t user_id, bool active_state)
{
StopHookCollection::iterator specified_hook_iter;
specified_hook_iter = m_stop_hooks.find (user_id);
if (specified_hook_iter == m_stop_hooks.end())
return false;
(*specified_hook_iter).second->SetIsActive (active_state);
return true;
}
void
Target::SetAllStopHooksActiveState (bool active_state)
{
StopHookCollection::iterator pos, end = m_stop_hooks.end();
for (pos = m_stop_hooks.begin(); pos != end; pos++)
{
(*pos).second->SetIsActive (active_state);
}
}
void
Target::RunStopHooks ()
{
if (!m_process_sp)
return;
if (m_stop_hooks.empty())
return;
StopHookCollection::iterator pos, end = m_stop_hooks.end();
// If there aren't any active stop hooks, don't bother either:
bool any_active_hooks = false;
for (pos = m_stop_hooks.begin(); pos != end; pos++)
{
if ((*pos).second->IsActive())
{
any_active_hooks = true;
break;
}
}
if (!any_active_hooks)
return;
CommandReturnObject result;
std::vector<ExecutionContext> exc_ctx_with_reasons;
std::vector<SymbolContext> sym_ctx_with_reasons;
ThreadList &cur_threadlist = m_process_sp->GetThreadList();
size_t num_threads = cur_threadlist.GetSize();
for (size_t i = 0; i < num_threads; i++)
{
lldb::ThreadSP cur_thread_sp = cur_threadlist.GetThreadAtIndex (i);
if (cur_thread_sp->ThreadStoppedForAReason())
{
lldb::StackFrameSP cur_frame_sp = cur_thread_sp->GetStackFrameAtIndex(0);
exc_ctx_with_reasons.push_back(ExecutionContext(m_process_sp.get(), cur_thread_sp.get(), cur_frame_sp.get()));
sym_ctx_with_reasons.push_back(cur_frame_sp->GetSymbolContext(eSymbolContextEverything));
}
}
// If no threads stopped for a reason, don't run the stop-hooks.
size_t num_exe_ctx = exc_ctx_with_reasons.size();
if (num_exe_ctx == 0)
return;
result.SetImmediateOutputFile (m_debugger.GetOutputFile().GetStream());
result.SetImmediateErrorFile (m_debugger.GetErrorFile().GetStream());
bool keep_going = true;
bool hooks_ran = false;
for (pos = m_stop_hooks.begin(); keep_going && pos != end; pos++)
{
// result.Clear();
StopHookSP cur_hook_sp = (*pos).second;
if (!cur_hook_sp->IsActive())
continue;
bool any_thread_matched = false;
for (size_t i = 0; keep_going && i < num_exe_ctx; i++)
{
if ((cur_hook_sp->GetSpecifier () == NULL
|| cur_hook_sp->GetSpecifier()->SymbolContextMatches(sym_ctx_with_reasons[i]))
&& (cur_hook_sp->GetThreadSpecifier() == NULL
|| cur_hook_sp->GetThreadSpecifier()->ThreadPassesBasicTests(exc_ctx_with_reasons[i].thread)))
{
if (!hooks_ran)
{
result.AppendMessage("\n** Stop Hooks **\n");
hooks_ran = true;
}
if (!any_thread_matched)
{
result.AppendMessageWithFormat("\n- Hook %d\n", cur_hook_sp->GetID());
any_thread_matched = true;
}
result.AppendMessageWithFormat("-- Thread %d\n", exc_ctx_with_reasons[i].thread->GetIndexID());
bool stop_on_continue = true;
bool stop_on_error = true;
bool echo_commands = false;
bool print_results = true;
GetDebugger().GetCommandInterpreter().HandleCommands (cur_hook_sp->GetCommands(),
&exc_ctx_with_reasons[i],
stop_on_continue,
stop_on_error,
echo_commands,
print_results,
result);
// If the command started the target going again, we should bag out of
// running the stop hooks.
if ((result.GetStatus() == eReturnStatusSuccessContinuingNoResult)
|| (result.GetStatus() == eReturnStatusSuccessContinuingResult))
{
result.AppendMessageWithFormat ("Aborting stop hooks, hook %d set the program running.", cur_hook_sp->GetID());
keep_going = false;
}
}
}
}
if (hooks_ran)
result.AppendMessage ("\n** End Stop Hooks **\n");
}
//--------------------------------------------------------------
// class Target::StopHook
//--------------------------------------------------------------
Target::StopHook::StopHook (lldb::TargetSP target_sp, lldb::user_id_t uid) :
UserID (uid),
m_target_sp (target_sp),
m_active (true),
m_commands (),
m_specifier_sp (),
m_thread_spec_ap(NULL)
{
}
Target::StopHook::StopHook (const StopHook &rhs) :
UserID (rhs.GetID()),
m_target_sp (rhs.m_target_sp),
m_commands (rhs.m_commands),
m_specifier_sp (rhs.m_specifier_sp),
m_active (rhs.m_active),
m_thread_spec_ap (NULL)
{
if (rhs.m_thread_spec_ap.get() != NULL)
m_thread_spec_ap.reset (new ThreadSpec(*rhs.m_thread_spec_ap.get()));
}
Target::StopHook::~StopHook ()
{
}
void
Target::StopHook::SetThreadSpecifier (ThreadSpec *specifier)
{
m_thread_spec_ap.reset (specifier);
}
void
Target::StopHook::GetDescription (Stream *s, lldb::DescriptionLevel level) const
{
int indent_level = s->GetIndentLevel();
s->SetIndentLevel(indent_level + 2);
s->Printf ("Hook: %d\n", GetID());
if (m_active)
s->Indent ("State: enabled\n");
else
s->Indent ("State: disabled\n");
if (m_specifier_sp)
{
s->Indent();
s->PutCString ("Specifier:\n");
s->SetIndentLevel (indent_level + 4);
m_specifier_sp->GetDescription (s, level);
s->SetIndentLevel (indent_level + 2);
}
if (m_thread_spec_ap.get() != NULL)
{
StreamString tmp;
s->Indent("Thread:\n");
m_thread_spec_ap->GetDescription (&tmp, level);
s->SetIndentLevel (indent_level + 4);
s->Indent (tmp.GetData());
s->PutCString ("\n");
s->SetIndentLevel (indent_level + 2);
}
s->Indent ("Commands: \n");
s->SetIndentLevel (indent_level + 4);
uint32_t num_commands = m_commands.GetSize();
for (uint32_t i = 0; i < num_commands; i++)
{
s->Indent(m_commands.GetStringAtIndex(i));
s->PutCString ("\n");
}
s->SetIndentLevel (indent_level);
}
//--------------------------------------------------------------
// class Target::SettingsController
//--------------------------------------------------------------
Target::SettingsController::SettingsController () :
UserSettingsController ("target", Debugger::GetSettingsController()),
m_default_architecture ()
{
m_default_settings.reset (new TargetInstanceSettings (*this, false,
InstanceSettings::GetDefaultName().AsCString()));
}
Target::SettingsController::~SettingsController ()
{
}
lldb::InstanceSettingsSP
Target::SettingsController::CreateInstanceSettings (const char *instance_name)
{
TargetInstanceSettings *new_settings = new TargetInstanceSettings (*GetSettingsController(),
false,
instance_name);
lldb::InstanceSettingsSP new_settings_sp (new_settings);
return new_settings_sp;
}
Added new target instance settings for execution settings: Targets can now specify some additional parameters for when we debug executables that can help with plug-in selection: target.execution-level = auto | user | kernel target.execution-mode = auto | dynamic | static target.execution-os-type = auto | none | halted | live On some systems, the binaries that are created are the same wether you use them to debug a kernel, or a user space program. Many times inspecting an object file can reveal what an executable should be. For these cases we can now be a little more complete by specifying wether to detect all of these things automatically (inspect the main executable file and select a plug-in accordingly), or manually to force the selection of certain plug-ins. To do this we now allow the specficifation of wether one is debugging a user space program (target.execution-level = user) or a kernel program (target.execution-level = kernel). We can also specify if we want to debug a program where shared libraries are dynamically loaded using a DynamicLoader plug-in (target.execution-mode = dynamic), or wether we will treat all symbol files as already linked at the correct address (target.execution-mode = static). We can also specify if the inferior we are debugging is being debugged on a bare board (target.execution-os-type = none), or debugging an OS where we have a JTAG or other direct connection to the inferior stops the entire OS (target.execution-os-type = halted), or if we are debugging a program on something that has live debug services (target.execution-os-type = live). For the "target.execution-os-type = halted" mode, we will need to create ProcessHelper plug-ins that allow us to extract the process/thread and other OS information by reading/writing memory. This should allow LLDB to be used for a wide variety of debugging tasks and handle them all correctly. llvm-svn: 125815
2011-02-18 09:44:25 +08:00
#define TSC_DEFAULT_ARCH "default-arch"
#define TSC_EXPR_PREFIX "expr-prefix"
#define TSC_EXEC_LEVEL "execution-level"
#define TSC_EXEC_MODE "execution-mode"
#define TSC_EXEC_OS_TYPE "execution-os-type"
static const ConstString &
GetSettingNameForDefaultArch ()
{
static ConstString g_const_string (TSC_DEFAULT_ARCH);
return g_const_string;
}
static const ConstString &
GetSettingNameForExpressionPrefix ()
{
static ConstString g_const_string (TSC_EXPR_PREFIX);
return g_const_string;
}
static const ConstString &
GetSettingNameForExecutionLevel ()
{
Added new target instance settings for execution settings: Targets can now specify some additional parameters for when we debug executables that can help with plug-in selection: target.execution-level = auto | user | kernel target.execution-mode = auto | dynamic | static target.execution-os-type = auto | none | halted | live On some systems, the binaries that are created are the same wether you use them to debug a kernel, or a user space program. Many times inspecting an object file can reveal what an executable should be. For these cases we can now be a little more complete by specifying wether to detect all of these things automatically (inspect the main executable file and select a plug-in accordingly), or manually to force the selection of certain plug-ins. To do this we now allow the specficifation of wether one is debugging a user space program (target.execution-level = user) or a kernel program (target.execution-level = kernel). We can also specify if we want to debug a program where shared libraries are dynamically loaded using a DynamicLoader plug-in (target.execution-mode = dynamic), or wether we will treat all symbol files as already linked at the correct address (target.execution-mode = static). We can also specify if the inferior we are debugging is being debugged on a bare board (target.execution-os-type = none), or debugging an OS where we have a JTAG or other direct connection to the inferior stops the entire OS (target.execution-os-type = halted), or if we are debugging a program on something that has live debug services (target.execution-os-type = live). For the "target.execution-os-type = halted" mode, we will need to create ProcessHelper plug-ins that allow us to extract the process/thread and other OS information by reading/writing memory. This should allow LLDB to be used for a wide variety of debugging tasks and handle them all correctly. llvm-svn: 125815
2011-02-18 09:44:25 +08:00
static ConstString g_const_string (TSC_EXEC_LEVEL);
return g_const_string;
}
Added new target instance settings for execution settings: Targets can now specify some additional parameters for when we debug executables that can help with plug-in selection: target.execution-level = auto | user | kernel target.execution-mode = auto | dynamic | static target.execution-os-type = auto | none | halted | live On some systems, the binaries that are created are the same wether you use them to debug a kernel, or a user space program. Many times inspecting an object file can reveal what an executable should be. For these cases we can now be a little more complete by specifying wether to detect all of these things automatically (inspect the main executable file and select a plug-in accordingly), or manually to force the selection of certain plug-ins. To do this we now allow the specficifation of wether one is debugging a user space program (target.execution-level = user) or a kernel program (target.execution-level = kernel). We can also specify if we want to debug a program where shared libraries are dynamically loaded using a DynamicLoader plug-in (target.execution-mode = dynamic), or wether we will treat all symbol files as already linked at the correct address (target.execution-mode = static). We can also specify if the inferior we are debugging is being debugged on a bare board (target.execution-os-type = none), or debugging an OS where we have a JTAG or other direct connection to the inferior stops the entire OS (target.execution-os-type = halted), or if we are debugging a program on something that has live debug services (target.execution-os-type = live). For the "target.execution-os-type = halted" mode, we will need to create ProcessHelper plug-ins that allow us to extract the process/thread and other OS information by reading/writing memory. This should allow LLDB to be used for a wide variety of debugging tasks and handle them all correctly. llvm-svn: 125815
2011-02-18 09:44:25 +08:00
static const ConstString &
GetSettingNameForExecutionMode ()
{
static ConstString g_const_string (TSC_EXEC_MODE);
return g_const_string;
}
static const ConstString &
GetSettingNameForExecutionOSType ()
{
static ConstString g_const_string (TSC_EXEC_OS_TYPE);
return g_const_string;
}
Added new target instance settings for execution settings: Targets can now specify some additional parameters for when we debug executables that can help with plug-in selection: target.execution-level = auto | user | kernel target.execution-mode = auto | dynamic | static target.execution-os-type = auto | none | halted | live On some systems, the binaries that are created are the same wether you use them to debug a kernel, or a user space program. Many times inspecting an object file can reveal what an executable should be. For these cases we can now be a little more complete by specifying wether to detect all of these things automatically (inspect the main executable file and select a plug-in accordingly), or manually to force the selection of certain plug-ins. To do this we now allow the specficifation of wether one is debugging a user space program (target.execution-level = user) or a kernel program (target.execution-level = kernel). We can also specify if we want to debug a program where shared libraries are dynamically loaded using a DynamicLoader plug-in (target.execution-mode = dynamic), or wether we will treat all symbol files as already linked at the correct address (target.execution-mode = static). We can also specify if the inferior we are debugging is being debugged on a bare board (target.execution-os-type = none), or debugging an OS where we have a JTAG or other direct connection to the inferior stops the entire OS (target.execution-os-type = halted), or if we are debugging a program on something that has live debug services (target.execution-os-type = live). For the "target.execution-os-type = halted" mode, we will need to create ProcessHelper plug-ins that allow us to extract the process/thread and other OS information by reading/writing memory. This should allow LLDB to be used for a wide variety of debugging tasks and handle them all correctly. llvm-svn: 125815
2011-02-18 09:44:25 +08:00
bool
Target::SettingsController::SetGlobalVariable (const ConstString &var_name,
const char *index_value,
const char *value,
const SettingEntry &entry,
const lldb::VarSetOperationType op,
Error&err)
{
Added new target instance settings for execution settings: Targets can now specify some additional parameters for when we debug executables that can help with plug-in selection: target.execution-level = auto | user | kernel target.execution-mode = auto | dynamic | static target.execution-os-type = auto | none | halted | live On some systems, the binaries that are created are the same wether you use them to debug a kernel, or a user space program. Many times inspecting an object file can reveal what an executable should be. For these cases we can now be a little more complete by specifying wether to detect all of these things automatically (inspect the main executable file and select a plug-in accordingly), or manually to force the selection of certain plug-ins. To do this we now allow the specficifation of wether one is debugging a user space program (target.execution-level = user) or a kernel program (target.execution-level = kernel). We can also specify if we want to debug a program where shared libraries are dynamically loaded using a DynamicLoader plug-in (target.execution-mode = dynamic), or wether we will treat all symbol files as already linked at the correct address (target.execution-mode = static). We can also specify if the inferior we are debugging is being debugged on a bare board (target.execution-os-type = none), or debugging an OS where we have a JTAG or other direct connection to the inferior stops the entire OS (target.execution-os-type = halted), or if we are debugging a program on something that has live debug services (target.execution-os-type = live). For the "target.execution-os-type = halted" mode, we will need to create ProcessHelper plug-ins that allow us to extract the process/thread and other OS information by reading/writing memory. This should allow LLDB to be used for a wide variety of debugging tasks and handle them all correctly. llvm-svn: 125815
2011-02-18 09:44:25 +08:00
if (var_name == GetSettingNameForDefaultArch())
{
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
m_default_architecture.SetTriple (value);
if (!m_default_architecture.IsValid())
err.SetErrorStringWithFormat ("'%s' is not a valid architecture or triple.", value);
}
return true;
}
bool
Target::SettingsController::GetGlobalVariable (const ConstString &var_name,
StringList &value,
Error &err)
{
Added new target instance settings for execution settings: Targets can now specify some additional parameters for when we debug executables that can help with plug-in selection: target.execution-level = auto | user | kernel target.execution-mode = auto | dynamic | static target.execution-os-type = auto | none | halted | live On some systems, the binaries that are created are the same wether you use them to debug a kernel, or a user space program. Many times inspecting an object file can reveal what an executable should be. For these cases we can now be a little more complete by specifying wether to detect all of these things automatically (inspect the main executable file and select a plug-in accordingly), or manually to force the selection of certain plug-ins. To do this we now allow the specficifation of wether one is debugging a user space program (target.execution-level = user) or a kernel program (target.execution-level = kernel). We can also specify if we want to debug a program where shared libraries are dynamically loaded using a DynamicLoader plug-in (target.execution-mode = dynamic), or wether we will treat all symbol files as already linked at the correct address (target.execution-mode = static). We can also specify if the inferior we are debugging is being debugged on a bare board (target.execution-os-type = none), or debugging an OS where we have a JTAG or other direct connection to the inferior stops the entire OS (target.execution-os-type = halted), or if we are debugging a program on something that has live debug services (target.execution-os-type = live). For the "target.execution-os-type = halted" mode, we will need to create ProcessHelper plug-ins that allow us to extract the process/thread and other OS information by reading/writing memory. This should allow LLDB to be used for a wide variety of debugging tasks and handle them all correctly. llvm-svn: 125815
2011-02-18 09:44:25 +08:00
if (var_name == GetSettingNameForDefaultArch())
{
// If the arch is invalid (the default), don't show a string for it
if (m_default_architecture.IsValid())
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
value.AppendString (m_default_architecture.GetArchitectureName());
return true;
}
else
err.SetErrorStringWithFormat ("unrecognized variable name '%s'", var_name.AsCString());
return false;
}
//--------------------------------------------------------------
// class TargetInstanceSettings
//--------------------------------------------------------------
TargetInstanceSettings::TargetInstanceSettings
(
UserSettingsController &owner,
bool live_instance,
const char *name
) :
Added new target instance settings for execution settings: Targets can now specify some additional parameters for when we debug executables that can help with plug-in selection: target.execution-level = auto | user | kernel target.execution-mode = auto | dynamic | static target.execution-os-type = auto | none | halted | live On some systems, the binaries that are created are the same wether you use them to debug a kernel, or a user space program. Many times inspecting an object file can reveal what an executable should be. For these cases we can now be a little more complete by specifying wether to detect all of these things automatically (inspect the main executable file and select a plug-in accordingly), or manually to force the selection of certain plug-ins. To do this we now allow the specficifation of wether one is debugging a user space program (target.execution-level = user) or a kernel program (target.execution-level = kernel). We can also specify if we want to debug a program where shared libraries are dynamically loaded using a DynamicLoader plug-in (target.execution-mode = dynamic), or wether we will treat all symbol files as already linked at the correct address (target.execution-mode = static). We can also specify if the inferior we are debugging is being debugged on a bare board (target.execution-os-type = none), or debugging an OS where we have a JTAG or other direct connection to the inferior stops the entire OS (target.execution-os-type = halted), or if we are debugging a program on something that has live debug services (target.execution-os-type = live). For the "target.execution-os-type = halted" mode, we will need to create ProcessHelper plug-ins that allow us to extract the process/thread and other OS information by reading/writing memory. This should allow LLDB to be used for a wide variety of debugging tasks and handle them all correctly. llvm-svn: 125815
2011-02-18 09:44:25 +08:00
InstanceSettings (owner, name ? name : InstanceSettings::InvalidName().AsCString(), live_instance),
m_expr_prefix_path (),
m_expr_prefix_contents (),
m_execution_level (eExecutionLevelAuto),
m_execution_mode (eExecutionModeAuto),
m_execution_os_type (eExecutionOSTypeAuto)
{
// CopyInstanceSettings is a pure virtual function in InstanceSettings; it therefore cannot be called
// until the vtables for TargetInstanceSettings are properly set up, i.e. AFTER all the initializers.
// For this reason it has to be called here, rather than in the initializer or in the parent constructor.
// This is true for CreateInstanceName() too.
if (GetInstanceName () == InstanceSettings::InvalidName())
{
ChangeInstanceName (std::string (CreateInstanceName().AsCString()));
m_owner.RegisterInstanceSettings (this);
}
if (live_instance)
{
const lldb::InstanceSettingsSP &pending_settings = m_owner.FindPendingSettings (m_instance_name);
CopyInstanceSettings (pending_settings,false);
//m_owner.RemovePendingSettings (m_instance_name);
}
}
TargetInstanceSettings::TargetInstanceSettings (const TargetInstanceSettings &rhs) :
InstanceSettings (*Target::GetSettingsController(), CreateInstanceName().AsCString())
{
if (m_instance_name != InstanceSettings::GetDefaultName())
{
const lldb::InstanceSettingsSP &pending_settings = m_owner.FindPendingSettings (m_instance_name);
CopyInstanceSettings (pending_settings,false);
//m_owner.RemovePendingSettings (m_instance_name);
}
}
TargetInstanceSettings::~TargetInstanceSettings ()
{
}
TargetInstanceSettings&
TargetInstanceSettings::operator= (const TargetInstanceSettings &rhs)
{
if (this != &rhs)
{
}
return *this;
}
void
TargetInstanceSettings::UpdateInstanceSettingsVariable (const ConstString &var_name,
const char *index_value,
const char *value,
const ConstString &instance_name,
const SettingEntry &entry,
lldb::VarSetOperationType op,
Error &err,
bool pending)
{
Added new target instance settings for execution settings: Targets can now specify some additional parameters for when we debug executables that can help with plug-in selection: target.execution-level = auto | user | kernel target.execution-mode = auto | dynamic | static target.execution-os-type = auto | none | halted | live On some systems, the binaries that are created are the same wether you use them to debug a kernel, or a user space program. Many times inspecting an object file can reveal what an executable should be. For these cases we can now be a little more complete by specifying wether to detect all of these things automatically (inspect the main executable file and select a plug-in accordingly), or manually to force the selection of certain plug-ins. To do this we now allow the specficifation of wether one is debugging a user space program (target.execution-level = user) or a kernel program (target.execution-level = kernel). We can also specify if we want to debug a program where shared libraries are dynamically loaded using a DynamicLoader plug-in (target.execution-mode = dynamic), or wether we will treat all symbol files as already linked at the correct address (target.execution-mode = static). We can also specify if the inferior we are debugging is being debugged on a bare board (target.execution-os-type = none), or debugging an OS where we have a JTAG or other direct connection to the inferior stops the entire OS (target.execution-os-type = halted), or if we are debugging a program on something that has live debug services (target.execution-os-type = live). For the "target.execution-os-type = halted" mode, we will need to create ProcessHelper plug-ins that allow us to extract the process/thread and other OS information by reading/writing memory. This should allow LLDB to be used for a wide variety of debugging tasks and handle them all correctly. llvm-svn: 125815
2011-02-18 09:44:25 +08:00
int new_enum = -1;
if (var_name == GetSettingNameForExpressionPrefix ())
{
switch (op)
{
default:
err.SetErrorToGenericError ();
err.SetErrorString ("Unrecognized operation. Cannot update value.\n");
return;
case lldb::eVarSetOperationAssign:
{
FileSpec file_spec(value, true);
if (!file_spec.Exists())
{
err.SetErrorToGenericError ();
err.SetErrorStringWithFormat ("%s does not exist.\n", value);
return;
}
DataBufferSP data_sp (file_spec.ReadFileContents());
if (!data_sp && data_sp->GetByteSize() == 0)
{
err.SetErrorToGenericError ();
err.SetErrorStringWithFormat ("Couldn't read from %s\n", value);
return;
}
m_expr_prefix_path = value;
m_expr_prefix_contents.assign(reinterpret_cast<const char *>(data_sp->GetBytes()), data_sp->GetByteSize());
}
return;
case lldb::eVarSetOperationAppend:
err.SetErrorToGenericError ();
err.SetErrorString ("Cannot append to a path.\n");
return;
case lldb::eVarSetOperationClear:
m_expr_prefix_path.clear ();
m_expr_prefix_contents.clear ();
return;
}
}
Added new target instance settings for execution settings: Targets can now specify some additional parameters for when we debug executables that can help with plug-in selection: target.execution-level = auto | user | kernel target.execution-mode = auto | dynamic | static target.execution-os-type = auto | none | halted | live On some systems, the binaries that are created are the same wether you use them to debug a kernel, or a user space program. Many times inspecting an object file can reveal what an executable should be. For these cases we can now be a little more complete by specifying wether to detect all of these things automatically (inspect the main executable file and select a plug-in accordingly), or manually to force the selection of certain plug-ins. To do this we now allow the specficifation of wether one is debugging a user space program (target.execution-level = user) or a kernel program (target.execution-level = kernel). We can also specify if we want to debug a program where shared libraries are dynamically loaded using a DynamicLoader plug-in (target.execution-mode = dynamic), or wether we will treat all symbol files as already linked at the correct address (target.execution-mode = static). We can also specify if the inferior we are debugging is being debugged on a bare board (target.execution-os-type = none), or debugging an OS where we have a JTAG or other direct connection to the inferior stops the entire OS (target.execution-os-type = halted), or if we are debugging a program on something that has live debug services (target.execution-os-type = live). For the "target.execution-os-type = halted" mode, we will need to create ProcessHelper plug-ins that allow us to extract the process/thread and other OS information by reading/writing memory. This should allow LLDB to be used for a wide variety of debugging tasks and handle them all correctly. llvm-svn: 125815
2011-02-18 09:44:25 +08:00
else if (var_name == GetSettingNameForExecutionLevel ())
{
UserSettingsController::UpdateEnumVariable (entry.enum_values, &new_enum, value, err);
if (err.Success())
m_execution_level = (ExecutionLevel)new_enum;
}
else if (var_name == GetSettingNameForExecutionMode ())
{
UserSettingsController::UpdateEnumVariable (entry.enum_values, &new_enum, value, err);
if (err.Success())
m_execution_mode = (ExecutionMode)new_enum;
}
else if (var_name == GetSettingNameForExecutionOSType ())
{
UserSettingsController::UpdateEnumVariable (entry.enum_values, &new_enum, value, err);
if (err.Success())
m_execution_os_type = (ExecutionOSType)new_enum;
}
}
void
Added new target instance settings for execution settings: Targets can now specify some additional parameters for when we debug executables that can help with plug-in selection: target.execution-level = auto | user | kernel target.execution-mode = auto | dynamic | static target.execution-os-type = auto | none | halted | live On some systems, the binaries that are created are the same wether you use them to debug a kernel, or a user space program. Many times inspecting an object file can reveal what an executable should be. For these cases we can now be a little more complete by specifying wether to detect all of these things automatically (inspect the main executable file and select a plug-in accordingly), or manually to force the selection of certain plug-ins. To do this we now allow the specficifation of wether one is debugging a user space program (target.execution-level = user) or a kernel program (target.execution-level = kernel). We can also specify if we want to debug a program where shared libraries are dynamically loaded using a DynamicLoader plug-in (target.execution-mode = dynamic), or wether we will treat all symbol files as already linked at the correct address (target.execution-mode = static). We can also specify if the inferior we are debugging is being debugged on a bare board (target.execution-os-type = none), or debugging an OS where we have a JTAG or other direct connection to the inferior stops the entire OS (target.execution-os-type = halted), or if we are debugging a program on something that has live debug services (target.execution-os-type = live). For the "target.execution-os-type = halted" mode, we will need to create ProcessHelper plug-ins that allow us to extract the process/thread and other OS information by reading/writing memory. This should allow LLDB to be used for a wide variety of debugging tasks and handle them all correctly. llvm-svn: 125815
2011-02-18 09:44:25 +08:00
TargetInstanceSettings::CopyInstanceSettings (const lldb::InstanceSettingsSP &new_settings, bool pending)
{
TargetInstanceSettings *new_settings_ptr = static_cast <TargetInstanceSettings *> (new_settings.get());
if (!new_settings_ptr)
return;
Added new target instance settings for execution settings: Targets can now specify some additional parameters for when we debug executables that can help with plug-in selection: target.execution-level = auto | user | kernel target.execution-mode = auto | dynamic | static target.execution-os-type = auto | none | halted | live On some systems, the binaries that are created are the same wether you use them to debug a kernel, or a user space program. Many times inspecting an object file can reveal what an executable should be. For these cases we can now be a little more complete by specifying wether to detect all of these things automatically (inspect the main executable file and select a plug-in accordingly), or manually to force the selection of certain plug-ins. To do this we now allow the specficifation of wether one is debugging a user space program (target.execution-level = user) or a kernel program (target.execution-level = kernel). We can also specify if we want to debug a program where shared libraries are dynamically loaded using a DynamicLoader plug-in (target.execution-mode = dynamic), or wether we will treat all symbol files as already linked at the correct address (target.execution-mode = static). We can also specify if the inferior we are debugging is being debugged on a bare board (target.execution-os-type = none), or debugging an OS where we have a JTAG or other direct connection to the inferior stops the entire OS (target.execution-os-type = halted), or if we are debugging a program on something that has live debug services (target.execution-os-type = live). For the "target.execution-os-type = halted" mode, we will need to create ProcessHelper plug-ins that allow us to extract the process/thread and other OS information by reading/writing memory. This should allow LLDB to be used for a wide variety of debugging tasks and handle them all correctly. llvm-svn: 125815
2011-02-18 09:44:25 +08:00
m_expr_prefix_path = new_settings_ptr->m_expr_prefix_path;
m_expr_prefix_contents = new_settings_ptr->m_expr_prefix_contents;
m_execution_level = new_settings_ptr->m_execution_level;
m_execution_mode = new_settings_ptr->m_execution_mode;
m_execution_os_type = new_settings_ptr->m_execution_os_type;
}
bool
TargetInstanceSettings::GetInstanceSettingsValue (const SettingEntry &entry,
const ConstString &var_name,
StringList &value,
Error *err)
{
Added new target instance settings for execution settings: Targets can now specify some additional parameters for when we debug executables that can help with plug-in selection: target.execution-level = auto | user | kernel target.execution-mode = auto | dynamic | static target.execution-os-type = auto | none | halted | live On some systems, the binaries that are created are the same wether you use them to debug a kernel, or a user space program. Many times inspecting an object file can reveal what an executable should be. For these cases we can now be a little more complete by specifying wether to detect all of these things automatically (inspect the main executable file and select a plug-in accordingly), or manually to force the selection of certain plug-ins. To do this we now allow the specficifation of wether one is debugging a user space program (target.execution-level = user) or a kernel program (target.execution-level = kernel). We can also specify if we want to debug a program where shared libraries are dynamically loaded using a DynamicLoader plug-in (target.execution-mode = dynamic), or wether we will treat all symbol files as already linked at the correct address (target.execution-mode = static). We can also specify if the inferior we are debugging is being debugged on a bare board (target.execution-os-type = none), or debugging an OS where we have a JTAG or other direct connection to the inferior stops the entire OS (target.execution-os-type = halted), or if we are debugging a program on something that has live debug services (target.execution-os-type = live). For the "target.execution-os-type = halted" mode, we will need to create ProcessHelper plug-ins that allow us to extract the process/thread and other OS information by reading/writing memory. This should allow LLDB to be used for a wide variety of debugging tasks and handle them all correctly. llvm-svn: 125815
2011-02-18 09:44:25 +08:00
if (var_name == GetSettingNameForExpressionPrefix ())
{
value.AppendString (m_expr_prefix_path.c_str(), m_expr_prefix_path.size());
}
Added new target instance settings for execution settings: Targets can now specify some additional parameters for when we debug executables that can help with plug-in selection: target.execution-level = auto | user | kernel target.execution-mode = auto | dynamic | static target.execution-os-type = auto | none | halted | live On some systems, the binaries that are created are the same wether you use them to debug a kernel, or a user space program. Many times inspecting an object file can reveal what an executable should be. For these cases we can now be a little more complete by specifying wether to detect all of these things automatically (inspect the main executable file and select a plug-in accordingly), or manually to force the selection of certain plug-ins. To do this we now allow the specficifation of wether one is debugging a user space program (target.execution-level = user) or a kernel program (target.execution-level = kernel). We can also specify if we want to debug a program where shared libraries are dynamically loaded using a DynamicLoader plug-in (target.execution-mode = dynamic), or wether we will treat all symbol files as already linked at the correct address (target.execution-mode = static). We can also specify if the inferior we are debugging is being debugged on a bare board (target.execution-os-type = none), or debugging an OS where we have a JTAG or other direct connection to the inferior stops the entire OS (target.execution-os-type = halted), or if we are debugging a program on something that has live debug services (target.execution-os-type = live). For the "target.execution-os-type = halted" mode, we will need to create ProcessHelper plug-ins that allow us to extract the process/thread and other OS information by reading/writing memory. This should allow LLDB to be used for a wide variety of debugging tasks and handle them all correctly. llvm-svn: 125815
2011-02-18 09:44:25 +08:00
else if (var_name == GetSettingNameForExecutionLevel ())
{
value.AppendString (UserSettingsController::EnumToString (entry.enum_values, m_execution_level));
}
else if (var_name == GetSettingNameForExecutionMode ())
{
value.AppendString (UserSettingsController::EnumToString (entry.enum_values, m_execution_mode));
}
else if (var_name == GetSettingNameForExecutionOSType ())
{
value.AppendString (UserSettingsController::EnumToString (entry.enum_values, m_execution_os_type));
}
else
{
if (err)
err->SetErrorStringWithFormat ("unrecognized variable name '%s'", var_name.AsCString());
return false;
}
return true;
}
const ConstString
TargetInstanceSettings::CreateInstanceName ()
{
StreamString sstr;
static int instance_count = 1;
sstr.Printf ("target_%d", instance_count);
++instance_count;
const ConstString ret_val (sstr.GetData());
return ret_val;
}
//--------------------------------------------------
// Target::SettingsController Variable Tables
//--------------------------------------------------
SettingEntry
Target::SettingsController::global_settings_table[] =
{
Added new target instance settings for execution settings: Targets can now specify some additional parameters for when we debug executables that can help with plug-in selection: target.execution-level = auto | user | kernel target.execution-mode = auto | dynamic | static target.execution-os-type = auto | none | halted | live On some systems, the binaries that are created are the same wether you use them to debug a kernel, or a user space program. Many times inspecting an object file can reveal what an executable should be. For these cases we can now be a little more complete by specifying wether to detect all of these things automatically (inspect the main executable file and select a plug-in accordingly), or manually to force the selection of certain plug-ins. To do this we now allow the specficifation of wether one is debugging a user space program (target.execution-level = user) or a kernel program (target.execution-level = kernel). We can also specify if we want to debug a program where shared libraries are dynamically loaded using a DynamicLoader plug-in (target.execution-mode = dynamic), or wether we will treat all symbol files as already linked at the correct address (target.execution-mode = static). We can also specify if the inferior we are debugging is being debugged on a bare board (target.execution-os-type = none), or debugging an OS where we have a JTAG or other direct connection to the inferior stops the entire OS (target.execution-os-type = halted), or if we are debugging a program on something that has live debug services (target.execution-os-type = live). For the "target.execution-os-type = halted" mode, we will need to create ProcessHelper plug-ins that allow us to extract the process/thread and other OS information by reading/writing memory. This should allow LLDB to be used for a wide variety of debugging tasks and handle them all correctly. llvm-svn: 125815
2011-02-18 09:44:25 +08:00
// var-name var-type default enum init'd hidden help-text
// ================= ================== =========== ==== ====== ====== =========================================================================
{ TSC_DEFAULT_ARCH , eSetVarTypeString , NULL , NULL, false, false, "Default architecture to choose, when there's a choice." },
{ NULL , eSetVarTypeNone , NULL , NULL, false, false, NULL }
};
static lldb::OptionEnumValueElement
g_execution_level_enums[] =
{
{ eExecutionLevelAuto , "auto" , "Automatically detect the execution level (user/kernel)." },
{ eExecutionLevelKernel , "kernel" , "Treat executables as kernel executables." },
{ eExecutionLevelUser , "user" , "Treat executables as user space executables." },
{ 0 , NULL , NULL }
};
static lldb::OptionEnumValueElement
g_execution_mode_enums[] =
{
{ eExecutionModeAuto , "auto" , "Automatically detect the execution mode (static/dynamic)." },
{ eExecutionModeStatic , "static" , "All executables are static and addresses at the virtual addresses in the object files." },
{ eExecutionModeDynamic , "dynamic" , "Executables and shared libraries are dynamically loaded.." },
{ 0 , NULL , NULL }
};
static lldb::OptionEnumValueElement
g_execution_os_enums[] =
{
{ eExecutionOSTypeAuto , "auto" , "Automatically detect the execution OS (none/halted/live)." },
{ eExecutionOSTypeNone , "none" , "There is no operating system available (no processes or threads)." },
{ eExecutionOSTypeHalted, "halted" , "There is an operating system, but it is halted when the debugger is halted. "
"Processes and threads must be discovered by accessing symbols and reading "
"memory." },
{ eExecutionOSTypeLive , "live" , "There is a live operating system with debug services that can be used to "
"get processes, threads and theirs states." },
{ 0, NULL, NULL }
};
SettingEntry
Target::SettingsController::instance_settings_table[] =
{
Added new target instance settings for execution settings: Targets can now specify some additional parameters for when we debug executables that can help with plug-in selection: target.execution-level = auto | user | kernel target.execution-mode = auto | dynamic | static target.execution-os-type = auto | none | halted | live On some systems, the binaries that are created are the same wether you use them to debug a kernel, or a user space program. Many times inspecting an object file can reveal what an executable should be. For these cases we can now be a little more complete by specifying wether to detect all of these things automatically (inspect the main executable file and select a plug-in accordingly), or manually to force the selection of certain plug-ins. To do this we now allow the specficifation of wether one is debugging a user space program (target.execution-level = user) or a kernel program (target.execution-level = kernel). We can also specify if we want to debug a program where shared libraries are dynamically loaded using a DynamicLoader plug-in (target.execution-mode = dynamic), or wether we will treat all symbol files as already linked at the correct address (target.execution-mode = static). We can also specify if the inferior we are debugging is being debugged on a bare board (target.execution-os-type = none), or debugging an OS where we have a JTAG or other direct connection to the inferior stops the entire OS (target.execution-os-type = halted), or if we are debugging a program on something that has live debug services (target.execution-os-type = live). For the "target.execution-os-type = halted" mode, we will need to create ProcessHelper plug-ins that allow us to extract the process/thread and other OS information by reading/writing memory. This should allow LLDB to be used for a wide variety of debugging tasks and handle them all correctly. llvm-svn: 125815
2011-02-18 09:44:25 +08:00
// var-name var-type default enum-table init'd hidden help-text
// ================= ================== =========== ========================= ====== ====== =========================================================================
{ TSC_EXPR_PREFIX , eSetVarTypeString , NULL , NULL , false, false, "Path to a file containing expressions to be prepended to all expressions." },
{ TSC_EXEC_LEVEL , eSetVarTypeEnum , "auto" , g_execution_level_enums , false, false, "Sets the execution level for a target." },
{ TSC_EXEC_MODE , eSetVarTypeEnum , "auto" , g_execution_mode_enums , false, false, "Sets the execution mode for a target." },
{ TSC_EXEC_OS_TYPE , eSetVarTypeEnum , "auto" , g_execution_os_enums , false, false, "Sets the execution OS for a target." },
{ NULL , eSetVarTypeNone , NULL , NULL , false, false, NULL }
};