<rdar://problem/12462048>

LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings:

target.arg0 (string) =

There is also the program argument that are

<rdar://problem/12462048>

LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings:

target.arg0 (string) =

There is also the program argument that are separate from the first argument that have existed for a while:

target.run-args (arguments) =

When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the:
- resolved executable path
- argv0
- program args

Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision.

llvm-svn: 166137

show more ...

Bunch of cleanups for warnings found by the llvm static analyzer.

llvm-svn: 165808

Ran the sources through the compiler with -Wshadow warnings
enabled after we'd found a few bugs that were caused by shadowed
local variables; the most important issue this turned up was
a common mist

Ran the sources through the compiler with -Wshadow warnings
enabled after we'd found a few bugs that were caused by shadowed
local variables; the most important issue this turned up was
a common mistake of trying to obtain a mutex lock for the scope
of a code block by doing

Mutex::Locker(m_map_mutex);

This doesn't assign the lock object to a local variable; it is
a temporary that has its dtor called immediately. Instead,

Mutex::Locker locker(m_map_mutex);

does what is intended. For some reason -Wshadow happened to
highlight these as shadowed variables.

I also fixed a few obivous and easy shadowed variable issues
across the code base but there are a couple dozen more that
should be fixed when someone has a free minute.
<rdar://problem/12437585>

llvm-svn: 165269

show more ...

Wrapped up the work I am going to do for now for the "add-dsym" or "target symfile add" command.

We can now do:

Specify a path to a debug symbols file:
(lldb) add-dsym <path-to-dsym>

Go and downlo

Wrapped up the work I am going to do for now for the "add-dsym" or "target symfile add" command.

We can now do:

Specify a path to a debug symbols file:
(lldb) add-dsym <path-to-dsym>

Go and download the dSYM file for the "libunc.dylib" module in your target:
(lldb) add-dsym --shlib libunc.dylib

Go and download the dSYM given a UUID:
(lldb) add-dsym --uuid <UUID>

Go and download the dSYM file for the current frame:
(lldb) add-dsym --frame

llvm-svn: 164806

show more ...

Added the ability to download a symboled executable and symbol file given a UUID.

llvm-svn: 164753

Made the help for the -n option on
"target image lookup" a bit better
documented by indicating that it takes
symbols OR functions.

<rdar://problem/12281325>

llvm-svn: 163839

<rdar://problem/11374963>

Partial fix for the above radar where we now resolve dsym mach-o files within the dSYM bundle when using "add-dsym" through the platform.

llvm-svn: 163676

Change the NULL to a 0 since we need a uint32_t

llvm-svn: 163625

<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 implem

<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

show more ...

Fix a redundant computation.

llvm-svn: 162794

rdar://problem/11324515

'add-dsym' (aka 'target symbols add') should display error messages when dsym file is not found
or the dsym uuid does not match any existing modules. Add TestAddDsymCommand.p

rdar://problem/11324515

'add-dsym' (aka 'target symbols add') should display error messages when dsym file is not found
or the dsym uuid does not match any existing modules. Add TestAddDsymCommand.py test file.

llvm-svn: 162332

show more ...

rdar://problem/12096295

Add an lldb command line option to specify a core file: --core/-c.
For consistency, change the "target create" command to also use --core.

llvm-svn: 161993

Add a new 'target modules show-unwind' command to show the different
UnwindPlans for a function. This specifically does not use any
previously-generated UnwindPlans so if any logging is performed
wh

Add a new 'target modules show-unwind' command to show the different
UnwindPlans for a function. This specifically does not use any
previously-generated UnwindPlans so if any logging is performed
while creating the UnwindPlans, it will be repeated. This is
useful for when an lldb stack trace is not correct and you want
to gather diagnostic information from the user -- they can do
log enable -v lldb unwind, image show-unwind of the function, and
you'll get the full logging as the UnwindPlans are recreated.

llvm-svn: 160095

show more ...

Fixed an issue where if you ask to search the global list of modules for a module with "target modules list", if it found a match in the current target, it would skip looking at the global list. Now

Fixed an issue where if you ask to search the global list of modules for a module with "target modules list", if it found a match in the current target, it would skip looking at the global list. Now if you ask for the global list, we use it and skip the target.

llvm-svn: 160072

show more ...

Make error messages more user-friendly for the 'target delete' command.

llvm-svn: 159927

<rdar://problem/11357711>

Fixed a crasher where the section load list was not thread safe.

llvm-svn: 159884

Fixed the "target modules list" to not crash in Debug builds due to an assertion where the mutex in the "module_list" local variable would assert when the lldb_private::Mutex would destruct. What was

Fixed the "target modules list" to not crash in Debug builds due to an assertion where the mutex in the "module_list" local variable would assert when the lldb_private::Mutex would destruct. What was happening was the mutex in the module list was being locked by a local locker object and then "module_list" would get destroyed before the locker and the locker still had the mutex locked which would cause the pthread call to destroy the mutex to fail with "Resource busy" and it would cause a mutex leak.

llvm-svn: 159291

show more ...

Make raw & parsed commands subclasses of CommandObject rather than having the raw version implement an
Execute which was never going to get run and another ExecuteRawCommandString. Took the knowled

Make raw & parsed commands subclasses of CommandObject rather than having the raw version implement an
Execute which was never going to get run and another ExecuteRawCommandString. Took the knowledge of how
to prepare raw & parsed commands out of CommandInterpreter and put it in CommandObject where it belongs.

Also took all the cases where there were the subcommands of Multiword commands declared in the .h file for
the overall command and moved them into the .cpp file.

Made the CommandObject flags work for raw as well as parsed commands.

Made "expr" use the flags so that it requires you to be paused to run "expr".

llvm-svn: 158235

show more ...

Added the --all argument to "target modules lookup"
that forces all matches to be looked up. When --all
is not passed, and the current execution frame can
be used to narrow down the search, "target

Added the --all argument to "target modules lookup"
that forces all matches to be looked up. When --all
is not passed, and the current execution frame can
be used to narrow down the search, "target modules
lookup" will try searching in that specific frame
first. Only if nothing is turned up there will it
go on to search all modules.

This feature is currently enabled only for types.

llvm-svn: 158107

show more ...

-i option should apply to "-n" as well as "-F".

llvm-svn: 157960

We were accessing the ModuleList in the target without locking it for tasks like
setting breakpoints. That's dangerous, since while we are setting a breakpoint,
the target might hit the dyld load no

We were accessing the ModuleList in the target without locking it for tasks like
setting breakpoints. That's dangerous, since while we are setting a breakpoint,
the target might hit the dyld load notification, and start removing modules from
the list. This change adds a GetMutex accessor to the ModuleList class, and
uses it whenever we are accessing the target's ModuleList (as returned by GetImages().)

<rdar://problem/11552372>

llvm-svn: 157668

show more ...

<rdar://problem/11386214>
<rdar://problem/11455913>

"target symbol add" should flush the cached frames
"register write" should flush the thread state in case registers modifications change stack

<rdar://problem/11386214>
<rdar://problem/11455913>

"target symbol add" should flush the cached frames
"register write" should flush the thread state in case registers modifications change stack



llvm-svn: 157042

show more ...

Modified "image lookup -t <typename>" to expand typedefs.

llvm-svn: 156845

<rdar://problem/11455398>

Add "--name" option to "image lookup" that will search both functions and symbols.

Also made all of the output from any of the "image lookup" commands be the same regardle

<rdar://problem/11455398>

Add "--name" option to "image lookup" that will search both functions and symbols.

Also made all of the output from any of the "image lookup" commands be the same regardless of the lookup type (function name, symbol name, func or symbol, file and line, address, etc). The --verbose or -v option also will expand the results as needed and display things so they look the same.

llvm-svn: 156835

show more ...

Don't expose the pthread_mutex_t underlying the Mutex & Mutex::Locker classes.
No one was using it and Locker(pthread_mutex_t *) immediately asserts for
pthread_mutex_t's that don't come from a Mu

Don't expose the pthread_mutex_t underlying the Mutex & Mutex::Locker classes.
No one was using it and Locker(pthread_mutex_t *) immediately asserts for
pthread_mutex_t's that don't come from a Mutex anyway. Rather than try to make
that work, we should maintain the Mutex abstraction and not pass around the
platform implementation...

Make Mutex::Locker::Lock take a Mutex & or a Mutex *, and remove the constructor
taking a pthread_mutex_t *. You no longer need to call Mutex::GetMutex to pass
your mutex to a Locker (you can't in fact, since I made it private.)

llvm-svn: 156221

show more ...