Cast to `const uint8_t *` instead of `uint8_t *` to avoid the warning
from GCC.
EmulationStateARM.cpp:206:34: warning: cast from type 'const void*' to type 'uint8_t* {aka unsigned char*}' casts away qualifiers [-Wcast-qual]
Cast to `const uint32_t *` and the explicitly cast away the const-ness
of the value. This seems pretty sketchy as the `DataExtractor` holds a
const reference to the data. However, this is no worse than before.
ObjectFilePECOFF.cpp:540:78: warning: cast from type 'const uint8_t* {aka const unsigned char*}' to type 'uint32_t* {aka unsigned int*}' casts away qualifiers [-Wcast-qual]
llvm-svn: 308489
Summary:
The classes have no dependencies, and they are used both by lldb and
lldb-server, so it makes sense for them to live in the lowest layers.
Reviewers: zturner, jingham
Subscribers: emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D34746
llvm-svn: 306682
Summary:
instead of using a boolean to differentiate between the two section
types, use an enum to make the intent clearer.
I also remove the RegisterKind argument from the constructor, as this
can be deduced from the Type argument.
Reviewers: clayborg, jasonmolenda
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D34681
llvm-svn: 306521
Summary: Reported by coverity, I don't know how to provide a test.
Reviewers: zturner
Subscribers: lldb-commits, emaste
Differential Revision: https://reviews.llvm.org/D34550
llvm-svn: 306134
Summary:
This is basically a revert of D16107 and parts of D10800, which were
trying to get vdso loading working. They did this by implementing a
generic load-an-elf-file from memory approach, which is not correct,
since we cannot assume that an elf file is loaded in memory in full (it
usually isn't, as there's no need to load section headers for example).
This meant that we would read garbage instead of section sizes, and if
that garbage happened to be a large number, we would crash while trying
to allocate a buffer to accomodate the hypothetical section.
Instead of this, I add a bit of custom code to load the vdso to
DynamicLoaderPOSIXDYLD (which already needed to handle the vdso
specially). I determine the size of the memory to read using
Process::GetMemoryRegionInfo, which is information coming from the OS,
and cannot be forged by a malicious/misbehaving application.
Reviewers: eugene, clayborg
Subscribers: lldb-commits, ravitheja, tberghammer, emaste
Differential Revision: https://reviews.llvm.org/D34352
llvm-svn: 305780
This creates a new library called BinaryFormat that has all of
the headers from llvm/Support containing structure and layout
definitions for various types of binary formats like dwarf, coff,
elf, etc as well as the code for identifying a file from its
magic.
Differential Revision: https://reviews.llvm.org/D33843
llvm-svn: 304864
The Timer destructor would grab a global mutex in order to update
execution time. Add a class to define a category once, statically; the
class adds itself to an atomic singly linked list, and thus subsequent
updates only need to use an atomic rather than grab a lock and perform a
hashtable lookup.
Differential Revision: https://reviews.llvm.org/D32823
Patch by Scott Smith <scott.smith@purestorage.com>.
llvm-svn: 303058
This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.
A change of this magnitude cannot easily be done without
find and replace, but that has potential to catch unwanted
occurrences of common strings such as "Error". Every effort
was made to find all the obvious things such as the word "Error"
appearing in a string, etc, but it's possible there are still
some lingering occurences left around. Hopefully nothing too
serious.
llvm-svn: 302872
Summary:
If we have symbol information in a separate file, we need to be very
careful about presenting a unified section view of module to the rest of
the debugger. ObjectFileELF had code to handle that, but it was being
overly cautious -- the section->GetFileSize()!=0 meant that the
unification would fail for sections which do not occupy any space in the
object file (e.g., .bss). In my case, that manifested itself as not
being able to display the values of .bss variables properly as the
section associated with the variable did not have it's load address set
(because it was not present in the unified section list).
I test this by making sure the unified section list and the variables
refer to the same section.
Reviewers: eugene, zturner
Subscribers: tberghammer, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D32434
llvm-svn: 301917
Summary:
UniqueCStringMap "sorts" the entries for fast lookup, but really it only cares about uniqueness. ConstString can be compared by pointer alone, rather than with strcmp, resulting in much faster comparisons. Change the interface to take ConstString instead, and propagate use of the type to the callers where appropriate.
Reviewers: #lldb, clayborg
Reviewed By: clayborg
Subscribers: labath, jasonmolenda, lldb-commits
Differential Revision: https://reviews.llvm.org/D32316
Patch by Scott Smith <scott.smith@purestorage.com>.
llvm-svn: 301908
lldb should use when given a corefile.
This uses an LC_NOTE "main bin spec" or an LC_NOTE "kern ver str"
if they are present in a Mach-O core file.
Core files may have multiple different binaries -- different kernels,
or a mix of user process and kernel binaries -- and it can be
difficult for lldb to detect the correct one to use simply by looking
at the pages of memory. These two new LC_NOTE load commands allow
for the correct binary to be recorded unambiguously.
<rdar://problem/20878266>
llvm-svn: 300138
This adjusts header file includes for headers and source files
in Core. In doing so, one dependency cycle is eliminated
because all the includes from Core to that project were dead
includes anyway. In places where some files in other projects
were only compiling due to a transitive include from another
header, fixups have been made so that those files also include
the header they need. Tested on Windows and Linux, and plan
to address failures on OSX and FreeBSD after watching the
bots.
llvm-svn: 299714
Summary:
Add basic OpenBSD support. This is enough to be able to analyze core dumps for OpenBSD/amd64, OpenBSD/arm, OpenBSD/arm64 and OpenBSD/i386.
Note that part of the changes to source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp fix a bug that probably affects other platforms as well. The GetProgramHeaderByIndex() interface use 1-based indices, but in some case when looping over the headers the, the loop starts at 0 and misses the last header. This caused problems on OpenBSD since OpenBSD core dumps have the PT_NOTE segment as the last program header.
Reviewers: joerg, labath, krytarowski
Reviewed By: krytarowski
Subscribers: aemerson, emaste, rengolin, srhines, krytarowski, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31131
llvm-svn: 298810
Only do this when we are debugging an executable, since we
don't have a good way to trace from an ObjectFile back to its
containing executable. Detecting pre-run libs before running
is "best effort" in lldb, but this one is pretty easy.
llvm-svn: 298290
This functionality is subsumed by DataBufferLLVM, which is
also more efficient since it will try to mmap. However, we
don't yet support mmaping writable private sections, and in
some cases we were using ReadFileContents and then modifying
the buffer. To address that I've added a flag to the
DataBufferLLVM methods that allow you to map privately, which
disables the mmaping path entirely. Eventually we should teach
DataBufferLLVM to use mmap with writable private, but that is
orthogonal to this effort.
Differential Revision: https://reviews.llvm.org/D30622
llvm-svn: 297095
All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.
Differential Revision: https://reviews.llvm.org/D30559
llvm-svn: 296909
After a series of patches on the LLVM side to get the mmaping
code up to compatibility with LLDB's needs, it is now ready
to go, which means LLDB's custom mmapping code is redundant.
So this patch deletes it all and uses LLVM's code instead.
In the future, we could take this one step further and delete
even the lldb DataBuffer base class and rely entirely on
LLVM's facilities, but this is a job for another day.
Differential Revision: https://reviews.llvm.org/D30054
llvm-svn: 296159
This moves the following classes from Core -> Utility.
ConstString
Error
RegularExpression
Stream
StreamString
The goal here is to get lldbUtility into a state where it has
no dependendencies except on itself and LLVM, so it can be the
starting point at which to start untangling LLDB's dependencies.
These are all low level and very widely used classes, and
previously lldbUtility had dependencies up to lldbCore in order
to use these classes. So moving then down to lldbUtility makes
sense from both the short term and long term perspective in
solving this problem.
Differential Revision: https://reviews.llvm.org/D29427
llvm-svn: 293941
Summary:
Problem:
There are three filelds in the ELF header - e_phnum, e_shnum, and e_shstrndx -
that could be bigger than 64K and therefore do not fit in 16 bits reserved for
them in the header. If this happens, pretty often there is a special section at
index 0 which contains their real values for these fields in the section header
in the fields sh_info, sh_size, and sh_link respectively.
Fix:
- Rename original fields in the header declaration. We want to have them around
just in case.
- Reintroduce these fields as 32-bit members at the end of the header. By default
they are initialized from the header in Parse() method.
- In Parse(), detect the situation when the header might have been extended into
section info #0 and try to read it from the same data source.
- ObjectFileELF::GetModuleSpecifications accesses some of these fields but the
original parse uses too small data source. Re-parse the header if necessary
using bigger data source.
- ProcessElfCore::CreateInstance uses header with potentially sentinel values,
but it does not access these fields, so a comment here is enough.
Reviewers: labath
Reviewed By: labath
Subscribers: davidb, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D29095
Author: Eugene Birukov <eugenebi@hotmail.com>
llvm-svn: 293714
Summary: I was building lldb using cross mingw-w64 toolchain on Linux and observed some issues. This is first patch in the series to fix that build. It mostly corrects the case of include files and adjusts some #ifdefs from _MSC_VER to _WIN32 and vice versa. I built lldb on windows with VS after applying this patch to make sure it does not break the build there.
Reviewers: zturner, labath, abidh
Subscribers: ki.stfu, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D27759
llvm-svn: 289821
This diff
1. Adds a comment to ObjectFileELF.cpp about the current
approach to determining the OS.
2. Replaces the check in SymbolFileDWARF.cpp with a more robust one.
Test plan:
Built (on Linux) a test binary linked to a c++ shared library
which contains just an implementation of a function TestFunction,
the library (the binary itself) doesn't contain ELF notes
and EI_OSABI is set to System V.
Checked in lldb that now "p TestFunction()" works fine
(and doesn't work without this patch).
Differential revision: https://reviews.llvm.org/D27380
llvm-svn: 288687
This is a large API change that removes the two functions from
StreamString that return a std::string& and a const std::string&,
and instead provide one function which returns a StringRef.
Direct access to the underlying buffer violates the concept of
a "stream" which is intended to provide forward only access,
and makes porting to llvm::raw_ostream more difficult in the
future.
Differential Revision: https://reviews.llvm.org/D26698
llvm-svn: 287152
We shouldn't access past the end of an array, even if we think that the
layout of the struct containing the array is always what we expect. The
compiler is free to optimize away the stores as undefined behavior, and
in fact, GCC 6.2.1 claims it will do exactly this.
llvm-svn: 286093
Summary:
.. handling for windows path was completely broken because the function was
expecting \ as path separators, but we were passing it normalized file paths,
where these have been replaced by forward slashes. Apart from this, the function
was incorrect for posix paths as well in some corner cases, as well as being
generally hard to follow.
The corner cases were:
- /../bar -> should be same as /bar
- /bar/.. -> should be same as / (slightly dodgy as the former depends on /bar actually
existing, but since we're doing it in an abstract way, I think the
transformation is reasonable)
I rewrite the function to fix these corner cases and handle windows paths more
correctly. The function should now handle the posix paths (modulo symlinks, but
we cannot really do anything about that without a real filesystem). For windows
paths, there are a couple of corner cases left, mostly to do with drive letter
handling, which cannot be fixed until the rest of the class understands drive
letters better.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D26081
llvm-svn: 285593
Summary:
When the local lldb doesn't have access to a copy of the modules in the target, e.g. winphone, with this change now we read these modules from memory.
There are mainly 2 changes:
1. create pecoff object files from memory
2. read from memory when the local file is not available
Reviewers: sas, fjricci, zturner
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D24284
llvm-svn: 284422
Summary:
ObjectFileELF::RefineModuleDetailsFromNote() identifies Linux core dumps by searching for
library paths starting with /lib/x86_64-linux-gnu or /lib/i386-linux-gnu. This change widens the
test to allow for linux installations which have addition directories in the path.
Reviewers: ted, hhellyer, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D25179
llvm-svn: 284114
Summary:
It fixes the following compile warnings:
1. '0' flag ignored with precision and ‘%d’ gnu_printf format
2. enumeral and non-enumeral type in conditional expression
3. format ‘%d’ expects argument of type ‘int’, but argument 4 has type ...
4. enumeration value ‘...’ not handled in switch
5. cast from type ‘const uint64_t* {aka ...}’ to type ‘int64_t* {aka ...}’ casts away qualifiers
6. extra ‘;’
7. comparison between signed and unsigned integer expressions
8. variable ‘register_operand’ set but not used
9. control reaches end of non-void function
Reviewers: jingham, emaste, zturner, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D24331
llvm-svn: 281191
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
and we couldn't find a dyld binary on the debug system, override
that setting and read dyld out of memory - we need to put an
internal breakpoint on dyld to register binaries being loaded or
unloaded; the debugger won't work right without dyld symbols.
<rdar://problem/27857025>
llvm-svn: 279704
It's always hard to remember when to include this file, and
when you do include it it's hard to remember what preprocessor
check it needs to be behind, and then you further have to remember
whether it's windows.h or win32.h which you need to include.
This patch changes the name to PosixApi.h, which is more appropriately
named, and makes it independent of any preprocessor setting.
There's still the issue of people not knowing when to include this,
because there's not a well-defined set of things it exposes other
than "whatever is missing on Windows", but at least this should
make it less painful to fix when problems arise.
This patch depends on LLVM revision r278170.
llvm-svn: 278177
Summary:
There were places in the code, assuming(hardcoding) offsets
and types that were only valid for the x86_64 elf core file format.
The NT_PRSTATUS and NT_PRPSINFO structures are with the 64 bit layout.
I have reused them and parse i386 files manually, and fill them in the
same struct.
Also added some error handling during parsing that checks if the
available bytes in the buffer are enough to fill the structures.
The i386 core file test case now passes.
For reference on the structures layout, I generally used the
source of binutils (bfd, readelf)
Bug: https://llvm.org/bugs/show_bug.cgi?id=26947
Reviewers: labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D22917
llvm-svn: 277140
cache from ObjectFileMachO (very wrong place) to the DynamicLoader
plugins (better place). Not much change to the code itself, although
the old ObjectFileMachO method would try both the new dyld SPI and
reading the dyld_all_image_infos structure. In the new methods,
I've separated those into the appropriate DynamicLoader plugins.
llvm-svn: 277088
debugserver jGetSharedCacheInfo packet instead of reading
the dyld internal data structures directly. This code is
(currently) only used for ios native lldb's - I should really
move this ObjectFileMachO::GetProcessSharedCacheUUID method
somewhere else, it makes less and less sense being in the
file reader.
<rdar://problem/25251243>
llvm-svn: 276369
These are artifical symbols inside android oat files without any value
for the user while causing a significant perfoamce hit inside the
unwinder. We were already ignoring it inside system@framework@boot.oat
bot they have to be ignored in every oat file. Considering that oat
files are only used on android this have no effect on any other
platfrom.
llvm-svn: 274500
for TestNamespaceLookup.py; didn't see anything obviously wrong so I'll
need to look at this more closely before re-committing. (passed OK on
macOS ;)
llvm-svn: 273531
There's uses of "macosx" that will be more tricky to
change, like in triples (e.g. "x86_64-apple-macosx10.11") -
for now I'm just updating source comments and strings printed
for humans.
llvm-svn: 273524
In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly.
llvm-svn: 272276
which looks for binaries missing an LC_FUNCTION_STARTS section because
it was stripped/not emitted. If we see a normal user process binary
(executable, dylib, framework, bundle) without LC_FUNCTION_STARTS, that
is unusual and we should disallow instruction emulation because that
binary has likely been stripped a lot.
If this is a non-user process binary -- a kernel, a standalone bare-board
binary, a kernel extension (kext) -- and there is no LC_FUNCTION_STARTS,
we should not assume anything about the binary and allow instruction
emulation as we would normally do.
<rdar://problem/26453952>
llvm-svn: 270818
missing an LC_FUNCTION_STARTS section, we assume it has been
aggressively stripped (it is *very* unusual for anyone to strip
LC_FUNCTION_STARTS) so we disable assembly instruction unwind plan
creation.
Kernel extensions (kexts) don't have LC_FUNCTION_STARTS, but we
almost always have good symbol bounds just with the linker symbols.
So add an exception to allow assembly instruction unwind plan
creation for kexts even though they lack LC_FUNCTION_STARTS.
<rdar://problem/26453952>
llvm-svn: 270618
Patch by Nitesh Jain.
Summary: These patch fix thread step-out for hard and soft float.
Reviewers: jaydeep, bhushan, clayborg
Differential Revision: http://reviews.llvm.org/D20416
llvm-svn: 270564
The CL causes a build breakage on platforms where sizeof(double) == sizeof(long double)
and it incorrectly assumes that sizeof(double) and sizeof(long double) is the same
on the host and the target.
llvm-svn: 270214
This is a pretty straightforward first pass over removing a number of uses of
Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there
are interfaces which take Mutex::Locker & to lock internal locks. This patch
cleans up most of the easy cases. The only non-trivial change is in
CommandObjectTarget.cpp where a Mutex::Locker was split into two.
llvm-svn: 269877
Patch by Nitesh Jain.
Summary: The ArchSpec::m_flags will be set based on ELF flag ABI.
Reviewers: ovyalov, clayborg
Subscribers: lldb-commits, mohit.bhakkad, sagar, jaydeep, bhushan
Differential: D18858
llvm-svn: 269181
should not be used for this module -- for use when an ObjectFile
knows that it does not have meaningful or accurate function start
addresses.
More commonly, it is not clear that function start addresses are
missing in a module. There are certain cases on Mac OS X where we
can tell that a Mach-O binary has been stripped of this essential
information, and the unwinder can end up emulating many megabytes
of instructions for a single "function" in the binary.
When a Mach-O binary is missing both an LC_FUNCTION_STARTS load
command (very unusual) and an eh_frame section, then we will assume
it has also been stripped of symbols and that instruction emulation
will not be useful on this module.
<rdar://problem/25988067>
llvm-svn: 268475
Remove case handling elf arm attribute Tag_THUMB_ISA_use and setting architecture to thumb.
Differential revision: http://reviews.llvm.org/D19520
llvm-svn: 267550
Make sure we figure out correct plt entry field in case linker has generated a small value below realistic entry size like 4 bytes or below.
Differential revision: http://reviews.llvm.org/D19252
llvm-svn: 267405
RegisterContextLLDB::InitializeNonZerothFrame already has code to attempt
to detect and handle the case where the PC points beyond the end of a
function, but there are certain cases where this doesn't work correctly.
In fact, there are *two* different places where this detection is attempted,
and the failure is in fact a result of an unfortunate interaction between
those two separate attempts.
First, the ResolveSymbolContextForAddress routine is called with the
resolve_tail_call_address flag set to true. This causes the routine
to internally accept a PC pointing beyond the end of a function, and
still resolving the PC to that function symbol.
Second, the InitializeNonZerothFrame routine itself maintains a
"decr_pc_and_recompute_addr_range" flag and, if that turns out to
be true, itself decrements the PC by one and searches again for
a symbol at that new PC value.
Both approaches correctly identify the symbol associated with the PC.
However, the problem is now that later on, we also need to find the
DWARF CFI record associated with the PC. This is done in the
RegisterContextLLDB::GetFullUnwindPlanForFrame routine, and uses
the "m_current_offset_backed_up_one" member variable.
However, that variable only actually contains the PC "backed up by
one" if the *second* approach above was taken. If the function was
already identified via the first approach above, that member variable
is *not* backed up by one but simply points to the original PC.
This in turn causes GetEHFrameUnwindPlan to not correctly identify
the DWARF CFI record associated with the PC.
Now, in many cases, if the first method had to back up the PC by one,
we *still* use the second method too, because of this piece of code:
// Or if we're in the middle of the stack (and not "above" an asynchronous event like sigtramp),
// and our "current" pc is the start of a function...
if (m_sym_ctx_valid
&& GetNextFrame()->m_frame_type != eTrapHandlerFrame
&& GetNextFrame()->m_frame_type != eDebuggerFrame
&& addr_range.GetBaseAddress().IsValid()
&& addr_range.GetBaseAddress().GetSection() == m_current_pc.GetSection()
&& addr_range.GetBaseAddress().GetOffset() == m_current_pc.GetOffset())
{
decr_pc_and_recompute_addr_range = true;
}
In many cases, when the PC is one beyond the end of the current function,
it will indeed then be exactly at the start of the next function. But this
is not always the case, e.g. if there happens to be alignment padding
between the end of one function and the start of the next.
In those cases, we may sucessfully look up the function symbol via
ResolveSymbolContextForAddress, but *not* set decr_pc_and_recompute_addr_range,
and therefore fail to find the correct DWARF CFI record.
A very simple fix for this problem is to just never use the first method.
Call ResolveSymbolContextForAddress with resolve_tail_call_address set
to false, which will cause it to fail if the PC is beyond the end of
the current function; or else, identify the next function if the PC
is also at the start of the next function. In either case, we will
then set the decr_pc_and_recompute_addr_range variable and back up the
PC anyway, but this time also find the correct DWARF CFI.
A related problem is that the ResolveSymbolContextForAddress sometimes
returns a "symbol" with empty name. This turns out to be an ELF section
symbol. Now, usually those get type eSymbolTypeInvalid. However, there
is code in ObjectFileELF::ParseSymbols that tries to change the type of
invalid symbols to eSymbolTypeCode or eSymbolTypeData if the symbol
lies within the code or data section.
Unfortunately, this check also hits the symbol for the code section
itself, which is then marked as eSymbolTypeCode. While the size of
the section symbol is 0 according to the ELF file, LLDB considers
this size invalid and attempts to figure out the "correct" size.
Depending on how this goes, we may end up with a symbol that overlays
part of the code section, even outside areas covered by real function
symbols.
Therefore, if we call ResolveSymbolContextForAddress with PC pointing
beyond the end of a function, we may get this bogus section symbol.
This again means InitializeNonZerothFrame thinks we have a valid PC,
but then we don't find any unwind info for it.
The fix for this problem is me to simply always leave ELF section
symbols as type eSymbolTypeInvalid.
Differential Revision: http://reviews.llvm.org/D18975
llvm-svn: 267363
This adds basic parsing of the EABI attributes section. This section contains
additional information about the target for which the file was built. Attempt
to infer additional architecture information from that section.
llvm-svn: 267291
Code in ObjectFileELF::ParseTrampolineSymbols assumes that the sh_info
field of the .rel(a).plt section identifies the .plt section.
However, with recent GNU ld this is no longer true. As a result of this:
https://sourceware.org/bugzilla/show_bug.cgi?id=18169
in object files generated with current linkers the sh_info field of
.rel(a).plt now points to the .got.plt section (or .got on some targets).
This causes LLDB to fail to identify any PLT stubs, causing a number of
test case failures.
This patch changes LLDB to simply always look for the .plt section by
name. This should be safe across all linkers and targets.
Differential Revision: http://reviews.llvm.org/D18973
llvm-svn: 266316
This patch adds support for Linux on SystemZ:
- A new ArchSpec value of eCore_s390x_generic
- A new directory Plugins/ABI/SysV-s390x providing an ABI implementation
- Register context support
- Native Linux support including watchpoint support
- ELF core file support
- Misc. support throughout the code base (e.g. breakpoint opcodes)
- Test case updates to support the platform
This should provide complete support for debugging the SystemZ platform.
Not yet supported are optional features like transaction support (zEC12)
or SIMD vector support (z13).
There is no instruction emulation, since our ABI requires that all code
provide correct DWARF CFI at all PC locations in .eh_frame to support
unwinding (i.e. -fasynchronous-unwind-tables is on by default).
The implementation follows existing platforms in a mostly straightforward
manner. A couple of things that are different:
- We do not use PTRACE_PEEKUSER / PTRACE_POKEUSER to access single registers,
since some registers (access register) reside at offsets in the user area
that are multiples of 4, but the PTRACE_PEEKUSER interface only allows
accessing aligned 8-byte blocks in the user area. Instead, we use a s390
specific ptrace interface PTRACE_PEEKUSR_AREA / PTRACE_POKEUSR_AREA that
allows accessing a whole block of the user area in one go, so in effect
allowing to treat parts of the user area as register sets.
- SystemZ hardware does not provide any means to implement read watchpoints,
only write watchpoints. In fact, we can only support a *single* write
watchpoint (but this can span a range of arbitrary size). In LLDB this
means we support only a single watchpoint. I've set all test cases that
require read watchpoints (or multiple watchpoints) to expected failure
on the platform. [ Note that there were two test cases that install
a read/write watchpoint even though they nowhere rely on the "read"
property. I've changed those to simply use plain write watchpoints. ]
Differential Revision: http://reviews.llvm.org/D18978
llvm-svn: 266308
Build-id support is being added to lld and by default it may produce a
64-bit build-id.
Prior to this change lldb would reject such a build-id. However, it then
falls back to a 4-byte crc32, which is a poorer quality identifier.
Differential Revision: http://reviews.llvm.org/D18096
llvm-svn: 263432
Most address represented in lldb as section plus offset and handling of
absolute addresses is problematic in several location because of lack
of necessary information (e.g. Target) or because of performance issues.
This CL change the way ObjectFileELF handle the absolute symbols with
creating a pseudo section for each symbol. With this change all existing
code designed to work with addresses in the form of section plus offset
will work with absolute symbols as well.
Differential revision: http://reviews.llvm.org/D17450
llvm-svn: 261859
* Generate artificial symbol names from eh_fame during symbol parsing
so these symbols are already present when we calcualte the size of
the symbols where 0 is specified.
* Fix symbol size calculation for the last symbol in the file where
it have to last until the end of the parent section.
This is the re-commit of the original change after fixing some test
failures on OSX.
Differential revision: http://reviews.llvm.org/D16996
llvm-svn: 261205
the xcode project file to catch switch statements that have a
case that falls through unintentionally.
Define LLVM_FALLTHROUGH to indicate instances where a case has code
and intends to fall through. This should be in llvm/Support/Compiler.h;
Peter Collingbourne originally checked in there (r237766), then
reverted (r237941) because he didn't have time to mark up all the
'case' statements that were intended to fall through. I put together
a patch to get this back in llvm http://reviews.llvm.org/D17063 but
it hasn't been approved in the past week. I added a new
lldb-private-defines.h to hold the definition for now.
Every place in lldb where there is a comment that the fall-through
is intentional, I added LLVM_FALLTHROUGH to silence the warning.
I haven't tried to identify whether the fallthrough is a bug or
not in the other places.
I haven't tried to add this to the cmake option build flags.
This warning will only work for clang.
This build cleanly (with some new warnings) on macosx with clang
under xcodebuild, but if this causes problems for people on other
configurations, I'll back it out.
llvm-svn: 260930
* Generate artificial symbol names from eh_fame during symbol parsing
so these symbols are already present when we calcualte the size of
the symbols where 0 is specified.
* Fix symbol size calculation for the last symbol in the file where
it have to last until the end of the parent section.
Differential revision: http://reviews.llvm.org/D16996
llvm-svn: 260369
This patch adds logic to detect if underlying binary is using arm hard float abi and use that information while handling return values in ABISysV_arm.
Differential revision: http://reviews.llvm.org/D16627
llvm-svn: 259885
The file contained very similar 4 implementation of the same data
structure with a lot of duplicated code and some minor API differences.
This CL refactor the class to eliminate the duplicated codes and to
unify the APIs.
RangeMap.h also contained a class called AddressDataArray what have very
little added functionality over an std::vector and used only by
ObjectFileMacO The CL moves the class to ObjectFileMachO.cpp as it isn't
belongs into RangeMap.h and shouldn't be used in new places anyway
because of the little added functionality.
Differential revision: http://reviews.llvm.org/D16769
llvm-svn: 259538
This fixes the regression of several tests on Windows after rL258621.
The root problem is that ObjectFilePECOFF was not setting type information for the symbols, and the new CL rejects symbols without type information, breaking functionality like thread step-over.
The fix sets the type information for functions (and creates a TODO for other types).
Along the way, I fixed some typos and formatting that made the code I was debugging harder to understand.
In the long run, we should consider replacing most of ObjectFilePECOFF with the COFF parsing code from LLVM.
Differential Revision: http://reviews.llvm.org/D16563
llvm-svn: 258758
This fixes the `thread step-over` regression exposed by http://reviews.llvm.org/D16186 , which depends on the symbols having actual sizes. Nine tests on Windows had started failing as a result. They all work again with this fix.
Differential Revision: http://reviews.llvm.org/D16415
llvm-svn: 258429
set the triple's "vendor" field to Apple.
We don't want to assume a vendor of Apple for all Mach-O files -
this breaks x86_64 EFI debugging where they put non-Apple binaries
in a Mach-O format for ease of handling.
But on armv7, Apple's ABI always uses r7 as the frame pointer
register; if we don't set the Vendor field to Apple, we can pick
up a generic armv7 ABI where the fp is r11 (or r7 for thumb) which
breaks backtracing altogether.
Greg is reluctant for us to make any assumptions about the Vendor
here, but we'll see how this shakes out. It's such a big problem
on armv7 if we don't know this is using the Apple ABI that it's worth
trying this approach.
<rdar://problem/22137561>
llvm-svn: 258387
register set indicated by ARM_THREAD_STATE32 (value 9) instead of
the old ARM_THREAD_STATE (value 1); this patch changes lldb to
accept either register set flavor code.
<rdar://problem/24246257>
llvm-svn: 258289
Summary:
The issue arises because LLDB is not
able to read the vdso library correctly.
The fix adds memory allocation callbacks
to allocate sufficient memory in case the
requested offsets don't fit in the memory
buffer allocated for the ELF.
Reviewers: lldb-commits, clayborg, deepak2427, ovyalov, labath, tberghammer
Differential Revision: http://reviews.llvm.org/D16107
llvm-svn: 258122
The ELF symbol table always contain the size of the symbols so we
don't have to try to guess them based on the address of the next
symbol (it is needed for mach-o).
The change fixes an issue when a symbol is removed after a 0 size
symbol (e.g. because the second one is not public) what previously
caused the symbol lookup algorithm to end up with showing the 0 size
symbol even for the later addresses (what are not part of any symbol).
That symbol lookup error can confuse the user and also confuses the
current stack unwinder.
Re-commit this CL after fixing the issue with gcc-4.9.2 on i386 Linux.
Differential revision: http://reviews.llvm.org/D16186
llvm-svn: 258113
The ELF symbol table always contain the size of the symbols so we
don't have to try to guess them based on the address of the next
symbol (it is needed for mach-o).
The change fixes an issue when a symbol is removed after a 0 size
symbol (e.g. because the second one is not public) what previously
caused the symbol lookup algorithm to end up with showing the 0 size
symbol even for the later addresses (what are not part of any symbol).
That symbol lookup error can confuse the user and also confuses the
current stack unwinder.
Differential revision: http://reviews.llvm.org/D16186
llvm-svn: 258040
Summary:
This was used with the old ARM vs. Thumb detection code but is not
required anymore.
Reviewers: tberghammer, clayborg
Subscribers: fjricci, aemerson, lldb-commits, rengolin
Differential Revision: http://reviews.llvm.org/D16099
llvm-svn: 257429
(There are changes in the copies of these four files in the FreeBSD base
system, and I've changed these ones to reduce gratuitous diffs in future
imports.)
llvm-svn: 256723
Summary:
DWARF 5 proposes a reinvented .debug_macro section. This change follows
that spec.
Currently, only GCC produces the .debug_macro section and hence
the added test is annottated with expectedFailureClang.
Reviewers: spyffe, clayborg, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15437
llvm-svn: 255729
Saleem Abdulrasool