don't crash if we disable logging when some code already has a copy of the
logger. Prior to this fix, logs were handed out as pointers and if they were
held onto while a log got disabled, then it could cause a crash. Now all logs
are handed out as shared pointers so this problem shouldn't happen anymore.
We are also using our new shared pointers that put the shared pointer count
and the object into the same allocation for a tad better performance.
llvm-svn: 118319
it logs the function calls, their arguments and the return values. This is not
complete or polished, but I am committing it now, at the request of someone who
really wants to use it, even though it's not really done. It currently does not
attempt to log all the functions, just the most important ones. I will be
making further adjustments to the API logging code over the next few days/weeks.
(Suggestions for improvements are welcome).
Update the Python build scripts to re-build the swig C++ file whenever
the python-extensions.swig file is modified.
Correct the help for 'log enable' command (give it the correct number & type of
arguments).
llvm-svn: 117349
So the issue here was that we have lldb_private::FileSpec that by default was
always resolving a path when using the:
FileSpec::FileSpec (const char *path);
and in the:
void FileSpec::SetFile(const char *pathname, bool resolve = true);
This isn't what we want in many many cases. One example is you have "/tmp" on
your file system which is really "/private/tmp". You compile code in that
directory and end up with debug info that mentions "/tmp/file.c". Then you
type:
(lldb) breakpoint set --file file.c --line 5
If your current working directory is "/tmp", then "file.c" would be turned
into "/private/tmp/file.c" which won't match anything in the debug info.
Also, it should have been just a FileSpec with no directory and a filename
of "file.c" which could (and should) potentially match any instances of "file.c"
in the debug info.
So I removed the constructor that just takes a path:
FileSpec::FileSpec (const char *path); // REMOVED
You must now use the other constructor that has a "bool resolve" parameter that you must always supply:
FileSpec::FileSpec (const char *path, bool resolve);
I also removed the default parameter to SetFile():
void FileSpec::SetFile(const char *pathname, bool resolve);
And fixed all of the code to use the right settings.
llvm-svn: 116944
if the address comes from a data section.
Fixed an issue that could occur when looking up a symbol that has a zero
byte size where no match would be returned even if there was an exact symbol
match.
Cleaned up the section dump output and added the section type into the output.
llvm-svn: 116017
They will now be represented as:
eSymbolTypeFunction: eSymbolTypeCode with IsDebug() == true
eSymbolTypeGlobal: eSymbolTypeData with IsDebug() == true and IsExternal() == true
eSymbolTypeStatic: eSymbolTypeData with IsDebug() == true and IsExternal() == false
This simplifies the logic when dealing with symbols and allows for symbols
to be coalesced into a single symbol most of the time.
Enabled the minimal symbol table for mach-o again after working out all the
kinks. We now get nice concise symbol tables and debugging with DWARF in the
.o files with a debug map in the binary works well again. There were issues
where the SymbolFileDWARFDebugMap symbol file parser was using symbol IDs and
symbol indexes interchangeably. Now that all those issues are resolved
debugging is working nicely.
llvm-svn: 113678
member variables.
Modified lldb_private::Module to have an accessor that can be used to tell if
a module is a dynamic link editor (dyld) as there are functions in dyld on
darwin that mirror functions in libc (malloc, free, etc) that should not
be used when doing function lookups by name in expressions if there are more
than one match when looking up functions by name.
llvm-svn: 113313
Arrange that this then gets properly set on attach, or when a "file" is set.
Add a completer for "process attach -n".
Caveats: there isn't currently a way to handle multiple processes with the same name. That
will have to wait on a way to pass annotations along with the completion strings.
llvm-svn: 110624
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
Greg Clayton