llvm-project/lldb/source/Breakpoint/BreakpointResolverFileLine.cpp

113 lines
3.6 KiB
C++
Raw Normal View History

//===-- BreakpointResolverFileLine.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/Breakpoint/BreakpointResolverFileLine.h"
// C Includes
// C++ Includes
// Other libraries and framework includes
// Project includes
#include "lldb/Breakpoint/BreakpointLocation.h"
#include "lldb/Core/Log.h"
<rdar://problem/11757916> Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
2012-08-30 05:13:06 +08:00
#include "lldb/Core/Module.h"
#include "lldb/Core/StreamString.h"
<rdar://problem/11757916> Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
2012-08-30 05:13:06 +08:00
#include "lldb/Symbol/CompileUnit.h"
#include "lldb/Symbol/Function.h"
#include "lldb/lldb-private-log.h"
using namespace lldb;
using namespace lldb_private;
//----------------------------------------------------------------------
// BreakpointResolverFileLine:
//----------------------------------------------------------------------
BreakpointResolverFileLine::BreakpointResolverFileLine
(
Breakpoint *bkpt,
const FileSpec &file_spec,
uint32_t line_no,
bool check_inlines,
bool skip_prologue
) :
BreakpointResolver (bkpt, BreakpointResolver::FileLineResolver),
m_file_spec (file_spec),
m_line_number (line_no),
m_inlines (check_inlines),
m_skip_prologue(skip_prologue)
{
}
BreakpointResolverFileLine::~BreakpointResolverFileLine ()
{
}
Searcher::CallbackReturn
BreakpointResolverFileLine::SearchCallback
(
SearchFilter &filter,
SymbolContext &context,
Address *addr,
bool containing
)
{
SymbolContextList sc_list;
assert (m_breakpoint != NULL);
// There is a tricky bit here. You can have two compilation units that #include the same file, and
// in one of them the function at m_line_number is used (and so code and a line entry for it is generated) but in the
// other it isn't. If we considered the CU's independently, then in the second inclusion, we'd move the breakpoint
// to the next function that actually generated code in the header file. That would end up being confusing.
// So instead, we do the CU iterations by hand here, then scan through the complete list of matches, and figure out
// the closest line number match, and only set breakpoints on that match.
// Note also that if file_spec only had a file name and not a directory, there may be many different file spec's in
// the resultant list. The closest line match for one will not be right for some totally different file.
// So we go through the match list and pull out the sets that have the same file spec in their line_entry
// and treat each set separately.
const size_t num_comp_units = context.module_sp->GetNumCompileUnits();
for (size_t i = 0; i < num_comp_units; i++)
{
CompUnitSP cu_sp (context.module_sp->GetCompileUnitAtIndex (i));
if (cu_sp)
{
if (filter.CompUnitPasses(*cu_sp))
cu_sp->ResolveSymbolContext (m_file_spec, m_line_number, m_inlines, false, eSymbolContextEverything, sc_list);
}
}
StreamString s;
s.Printf ("for %s:%d ",
m_file_spec.GetFilename().AsCString("<Unknown>"),
m_line_number);
SetSCMatchesByLine (filter, sc_list, m_skip_prologue, s.GetData());
return Searcher::eCallbackReturnContinue;
}
Searcher::Depth
BreakpointResolverFileLine::GetDepth()
{
return Searcher::eDepthModule;
}
void
BreakpointResolverFileLine::GetDescription (Stream *s)
{
s->Printf ("file = '%s', line = %u", m_file_spec.GetPath().c_str(), m_line_number);
}
void
BreakpointResolverFileLine::Dump (Stream *s) const
{
}