The attached patch adds support for debugging 32-bit processes when running a 64-bit lldb on an x86_64 Linux system.
Making this work required two basic changes:
1) Getting lldb to report that it could debug 32-bit processes
2) Changing an assumption about how ptrace works when debugging cross-platform
For the first change, I took a conservative approach and only enabled this for x86_64 Linux platforms. It may be that the change I made in Host.cpp could be extended to other 64-bit Linux platforms, but I'm not familiar enough with the other platforms to know for sure.
For the second change, the Linux ProcessMonitor class was assuming that ptrace(PTRACE_[PEEK|POKE]DATA...) would read/write a "word" based on the child process word size. However, the ptrace documentation says that the "word" size read or written is "determined by the OS variant." I verified experimentally that when ptracing a 32-bit child from a 64-bit parent a 64-bit word is read or written.
llvm-svn: 163398
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
Switch over to the "*-apple-macosx" for desktop and "*-apple-ios" for iOS triples.
Also make the selection process for auto selecting platforms based off of an arch much better.
llvm-svn: 156354
Error
Host::RunShellCommand (const char *command,
const char *working_dir,
int *status_ptr,
int *signo_ptr,
std::string *command_output_ptr,
uint32_t timeout_sec);
This will allow us to use this functionality in the host lldb_private::Platform, and also use it in our lldb-platform binary. It leverages the existing code in Host::LaunchProcess and ProcessLaunchInfo.
llvm-svn: 154730
Each platform now knows if it can handle an architecture and a platform can be found using an architecture. Each platform can look at the arch, vendor and OS and know if it should be used or not.
llvm-svn: 153104
and also so we don't break them with our code changes.
The _only_ plug-ins that should be #ifdef'ed out and not compiled in LLDB
are those that only work when running natively on the host system.
This fixed bot the PlatformLinux and PlatformFreeBSD build breakages that
were due to ModuleSpec changes.
llvm-svn: 151539
solve the build break due to the lack of this method.
It also propose a solution to the API changes in RegisterContext.
I upgraded also the the python version in the makefile. My linux
installation has python2.7 and AFAIK also the latest ubuntu
has this version of python so maybe is worth upgrading.
Patch by Marco Minutoli <mminutoli@gmail.com>
[Note: I had to hand merge in the diffs since patch thinks it is a corrupt patch.]
llvm-svn: 131313
This method only needs to be overridden in the remote debugging case, the
base class handles the host case. Since we do not do remote debugging on
Linux yet and there is a typo that causes a build issue, just remove this
method for now.
llvm-svn: 129069
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
Greg Clayton