specify a list of functions which should be treated as trap handlers.
This will be primarily useful to people working in non-user-level
process debugging - kernels and other standalone environments.
For most people, the trap handler functions provided by the Platform
plugin will be sufficient.
<rdar://problem/15835846>, <rdar://problem/15982682>
llvm-svn: 201386
This was primarily working around problems where we weren't able
to identify trap handlers for different environments -- but instead,
I'm working to make it easier to specify those trap handler function
names.
llvm-svn: 201366
add a new pure virtual CalculateTrapHandlerSymbolNames() that Platform
subclasses must implement which fills in the function name list with any
trap handlers that are expected on that platform.
llvm-svn: 201364
Michael Sartain refactored RegisterContextPOSIX_* in r192332, and I must
have missed the now-shadowed variable when I rebased the FreeBSD MIPS64
register context after that.
llvm-svn: 201334
aka asynchronous signal handlers, which subclasses should fill
in as appropriate. For most Unix user process environments,
the one entry in this list is _sigtramp. For bare-board and
kernel environments, there will be different sets of trap
handlers.
The unwinder needs to know when a frame is a trap handler
because the rules it enforces for the frame "above" the
trap handler is different from most middle-of-the-stack frames.
<rdar://problem/15835846>
llvm-svn: 201300
They were enforcing 16-byte alignment on stack frames for Darwin x86 programs.
But we've found that trap handlers typically don't have the stack pointer
aligned correctly when a trap happens and lldb wasn't backtracing all
the way through. This method is only used as a safety guard to prevent
lldb's unwinder from using a bogus address as a stack frame - we'll still
enforce word-size alignment on stack frames so that should be fine.
Also rolled back akaylor's changes from August 2013 in r188952 which changed
the i386 ABI plugin to relax the CallFrameAddressIsValid offsets for non-Darwin
targets where only 4-byte alignment is enforced. Now Darwin is the same as
those environments.
<rdar://problem/15982682>
llvm-svn: 201292
Elf core files were collapsing core segments when the virtual memory
addresses were contiguous without checking if the core-file-backed
memory region was the same size as the segment's VMA region. Without
this extra check, any time regions were collapsed but the core-backed
region was smaller (and thus had a zero-filled hole at the end), the
collapse operation would break VMA to core file lookups for subsequent
collapsed regions.
This change fixes the following bug:
http://llvm.org/bugs/show_bug.cgi?id=18769
llvm-svn: 201214
This test was skipped as it used to segfault on FreeBSD. It seems
the original issue has since been fixed, so have the test run again.
llvm-svn: 201169
use a system-wide unique thread ID instead of a pthread_t to identify
the thread we want debug info for. Also, free some more memory regions
that needed to be freed.
llvm-svn: 201117
Although the interface to el_push should be a constant parameter (as it is on
Darwin), certain Linux distributions currently ship a header which does not
provide proper const correctness. This causes compilation failures on Linux.
Strip the constness on the parameter, which whilst incorrect, is mostly
harmless. The parameter will not be changed by the interface and so it is
acceptable to do this. When distributions have updated to a more correct
declaration, it would be nice to revert this change.
Addresses PR18784.
llvm-svn: 201092
ObjectFile::SetLoadAddress (Target &target,
lldb::addr_t value,
bool value_is_offset);
Now "value" is a slide if "value_is_offset" is true, and "value" is an image base address otherwise. All previous usage of this API was using slides.
Updated the ObjectFileELF and ObjectFileMachO SetLoadAddress methods to do the right thing.
Also updated the ObjectFileMachO::SetLoadAddress() function to not load __LINKEDIT when it isn't needed and to only load sections that belong to the executable object file.
llvm-svn: 201003
What was happening was:
1 - Xcode ran and stopped and was doing work on thread 2
2 - Users would type something in Xcode console on thread 1
3 - thread 3 would be running command interpreter thread and try to execute command but get "failed to get API lock" error for any command that wanted the target API lock (like "expression")
<rdar://problem/15775016>
llvm-svn: 200997
When a user says
type formatter add ... unsigned int
he most probably means to deal with the "unsigned int" type. However, given how the LLDB command parser works, that command will try to add the formatter to the TWO types 'unsigned' AND 'int'
Since this is unlikely to be what the user wants, warn about it, and suggest they can use quotes to override the debugger's understanding
llvm-svn: 200996
Provide a filter for libc++ std::atomic<T>
This just hides some implementation clutter and promotes the actual content to only child status
llvm-svn: 200984
Move some code that was in DynamicLoaderPOSIXDLYD into the
base class DynamicLoader. In the case of UpdateLoadedSections(),
the test to see whether a file is loadable (its address is zero)
is not generally applicable so that test is changed to a more
universally applicable check for the SHF_ALLOC flag on the section.
Also make it explicit that the reading of the module_id in
DynamicLoaderPOSIXDYLD::GetThreadLocalData() is using a hardcoded
size (of module_id) of 4, which might not be appropriate on
big-endian 64-bit systems, leaving a FIXME comment in place.
llvm-svn: 200939
We now properly detect when a result object has an immediate output stream and don't echo the results a second time.
<rdar://problem/15954906>
llvm-svn: 200882
Ed Maste