Prior to this we would display the typename for "TestObj<-1>" as "TestObj<4294967295>" when we showed the type. Expression parsing could also fail because we would fail to find the mangled name when evaluating expressions.
The issue was we were losing the signed'ness of the template integer parameter in DWARFASTParserClang.cpp.
<rdar://problem/25577041>
llvm-svn: 272434
For some reason, the conversion to taking the target lock when acquiring
the ExecutionContext was only done for some of the functions here. That was
allowing lock inversion in some complex uses.
<rdar://problem/26705635>
llvm-svn: 272354
For code like:
int g_global = 234;
int g_static = 345;
int main(int argc, char **argv)
{
int a = 22333;
static int g_int = 123;
return g_global + g_static + g_int + a;
}
If we stop at the "return" statement, we expect to see "argc", "argv", "a" and "g_int" when we type "frame variable" since "g_int" is a locally defined static variable, but we don't expect to see "g_global" or "g_static" unless we add the -g option to "frame variable".
llvm-svn: 272348
This enables a couple of tests which have been shown to run reliably on the
linux x86 buildbot. If you see a failure after this commit, feel free to add
the xfail back, but please make it as specific as possible (i.e., try to make
it not cover i386/x86_64 with clang-3.5, clang-3.9 or gcc-4.9).
llvm-svn: 272326
Address Size File off File size
---------- ---------- ---------- ----------
LC_SEGMENT 0x000f6000 0x00001000 0x1d509ee8 0x00001000 --- --- 0 0x00000000 __TEXT
LC_SEGMENT 0x0f600000 0x00100000 0x1d50aee8 0x00100000 --- --- 0 0x00000000 __TEXT
LC_SEGMENT 0x000f7000 0x00001000 0x1d60aee8 0x00001000 --- --- 0 0x00000000 __TEXT
Any if the user executes the following command:
(lldb) mem read 0xf6ff0
We would attempt to read 32 bytes from 0xf6ff0 but would only get 16 unless we loop through consecutive memory ranges that are contiguous in the address space, but not in the file data.
This fixes the ProcessMachCore::DoReadMemory() to do the right thing.
<rdar://problem/19729287>
llvm-svn: 272322
Previously we eliminated the randomized scheme for finding memory when the
underlying process cannot allocate memory, and replaced it with an algorithm
that starts the allocations at 00x.
This was more determinstic, but runs into problems on embedded targets where the
pages near 0x0 are in fact interesting memory. To deal with those cases, this
patch does two things:
- It makes the default fallback be an address that is less likely than 0x0 to
contain interesting information.
- Before falling back to this, it adds an algorithm that consults the
GetMemoryRegionInfo() API to see if it can find an unmapped area.
This should eliminate the randomness (and unpredictable memory accesseas) of the
previous scheme while making expressions more likely to return correct results.
<rdar://problem/25545573>
llvm-svn: 272301
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
IsPointedCString has problems with ValueObjects of type eTypeHostAddress. We should
figure out the right thing to do in that case, but the test is silly here because we're
reading a type we've defined, so we know it is a const char *, and if the memory is good,
we won't be able to read any characters, when we do ReadPointedString.
<rdar://problem/26612812>
llvm-svn: 272087
Rules are as follows for internal code using lldb::DisassemblerSP and lldb::InstructionSP:
1 - The disassembler needs to stay around as long as instructions do as the Instruction subclass now has a weak pointer to the disassembler
2 - The public API has been fixed so that if you get a SBInstruction, it will hold onto a strong reference to the disassembler in a new InstructionImpl class
This will keep code like like:
inst = lldb.target.ReadInstructions(frame.GetPCAddress(), 1).GetInstructionAtIndex(0)
inst.GetMnemonic()
Working as expected (not the SBInstructionList() that was returned by SBTarget.ReadInstructions() is gone, but "inst" has a strong reference inside of it to the disassembler and the instruction.
All code inside the LLDB shared library was verified to correctly hold onto the disassembler instance in all places.
<rdar://problem/24585496>
llvm-svn: 272069
Summary:
In the case of client sockets, we are not binding to a specific port, so we
should be able to just request a new one. Disregarding refactors, this code
has been here since the initial LLDB checkin, so I was unable to figure out
whether it was added as a fix for a specific problem, or just for symmetry
with server sockets, but I see no side-effect from removing it now. I was
still able to create 10000 connections within a couple of seconds, so I think
it's unlikely we will exhaust the port space (previously, I would get an
error after a couple thousand connections).
This fixes an occasional issue with connecting to the android debug bridge
deamon on OSX when running the test suite, which would occasionaly fail with
EADDRINUSE. My best guess is that this was happening because two processes
were assigned the same client port number, and then things blew up because
they were both trying to connect to the same ADB server port. I have not
observed this issue happening on Linux or Windows.
Reviewers: clayborg
Subscribers: tberghammer, danalbert, lldb-commits
Differential Revision: http://reviews.llvm.org/D21088
llvm-svn: 272041
When USE_SETUPTERM_WORKAROUND is enabled, we were calling setupterm() multiple times and leaking memory on each subsequent call. This is now fixed by calling setupterm() once in the constructor and tracking if we have already setup a terminal for a file descriptor.
Calls to "el_set (m_editline, EL_ADDFN, ..." were leaking memory. If we switch over to call el_wset with wide strings when LLDB_EDITLINE_USE_WCHAR is set, then we no longer leak memory each time we construct a new Editline object.
The calls to "el_set (m_editline, EL_ADDFN, ..." were changed over to call "el_wset (m_editline, EL_ADDFN, ...". Note that when LLDB_EDITLINE_USE_WCHAR is not defined, then el_wset is #define'ed to el_set. All strings are wrapped in EditLineConstString which will use wide strings when needed, and normal C strings when LLDB_EDITLINE_USE_WCHAR is not defined.
<rdar://problem/26677627>
llvm-svn: 272036
If a lldbinline test's source file changed language, then the Makefile wasn't
updated. This was a problem if the Makefile was checked into the repository.
Now lldbinline.py always regenerates the Makefile and asserts if the
newly-generated version is not the same as the one already there. This ensures
that the repository will never be out of date without a buildbot failing.
http://reviews.llvm.org/D21032
llvm-svn: 272024
as an asynchronous unwind plan source.
Two small fixes to the compact unwind dumper tool for
armv7 encodings.
A change to DWARFCallFrameInfo to strip the 0th bit on
addresses in eh_frame sections when armv7. In the
clang generated examples I have, the 0th bit is set for
thumb functions and that's causing the unwinder to pick
the wrong function for eh_frame info.
llvm-svn: 271970
Summary:
Because PIE executables have an e_type of llvm::ELF::ET_DYN,
they are not of type eTypeExecutable, and were being removed
when svr4 packets were used.
Reviewers: clayborg, ADodds, tfiala, sas
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20990
llvm-svn: 271899
return NULL for an invalid register.
The unwind logic asks for the "return address register" which doesn't exist
on x86/x86_64, returns -1 and calls this with -1 as a parameter, ends up
out of scope of the array bounds for g_register_infos and later SIGSEGVs
on accessing. This now matches the other GetRegisterInfoAtIndex for
other platforms.
llvm-svn: 271876
Summary:
Without this commit, when `log enable lldb expr` is enabled, the
disassembly of JIT'ed code is never displayed.
Reviewers: spyffe, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20312
llvm-svn: 271863
Some compilers do not mark up C++ functions as extern "C" in the DWARF, so LLDB
has to fall back (if it is about to give up finding a symbol) to using the base
name of the function.
This fix also ensures that we search by full name rather than "auto," which
could cause unrelated C++ names to be found. Finally, it adds a test case.
<rdar://problem/25094302>
llvm-svn: 271551
Summary: Fix missing return after checking that m_backend is not a pointer or reference type.
Reviewers: clayborg, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20875
llvm-svn: 271453
For Thread Sanitizer reports, LLDB tries to find a global variable declaration
corresponding to the racy address in order to provide a filename and line
number. This commit changes the lookup of the variable to use the mangled
name for lookup and fall back to the demangled version if unavailable. This
is needed to report locations of races on Swift global variables.
I've also added a test to make sure we look up C++ globals correctly.
rdar://problem/26459401
Differential Revision: http://reviews.llvm.org/D20760
llvm-svn: 271433
We need to verify that consecutive bitfields have higher offsets and don't overlap. The issues was found by running a broken version of recent clangs where the bitfield offsets were being emitted incorrectly. To guard against this we now verify and toss out any invalid bitfields and print a message that indicates to file a bug against the compiler.
<rdar://problem/25737621>
llvm-svn: 271343
This change implements dumping the executable, triple,
args and environment when using ProcessInfo::Dump().
It also tweaks the way Args::Dump() works so that it prints
a configurable label rather than argv[{index}]={value}. By
default it behaves the same, but if the Dump() method with
the additional arg is provided, it can be overridden. The
environment variables dumped as part of ProcessInfo::Dump()
make use of that.
lldb-server has been modified to dump the gdb-remote stub's
ProcessInfo before launching if the "gdb-remote process" channel
is logged.
llvm-svn: 271312
"ClearDIEs()" was being called too soon, before everyone was done using the DIEs.
This fix delays the calls to ::ClearDIEs() until all compile units have been indexed.
1 - Call "::ExtractDIEsIfNeeded()" on all compile units on separate threads. See if each CU has the DIEs parsed and remember this.
2 - Index all compile units on separate threads.
3 - Clear any DIEs in any compile units that didn't have their DIEs parsed after all compile units have been indexed.
Patch by phlav
Differential Revision: http://reviews.llvm.org/D20738
llvm-svn: 271209
r259714 introduces the transport method into the
URL passed to the gdb-remote stub. On debugserver,
this is not supported and prevented debugserver from
being launched by lldb-server in platform mode.
This change skips the transport method addition from
r259714 when on Apple hosts.
llvm-svn: 270961
I was investigating an odd crash in lldb when the breakpoint site
goes to bump the hit counts of the locations it implements. I noticed
that the BreakpointLocationCollection wasn't locking itself for access and
modification. I don't see how that can cause the crash I'm seeing, but still
this is the right thing to do...
<rdar://problem/25178205>
llvm-svn: 270939
We have seen cases where we have been unable to find an argument type for a function, or we find one from another language, and then we try to create a function type by calling:
lldb_private::ClangASTContext::CreateFunctionType(clang::ASTContext*, lldb_private::CompilerType const&, lldb_private::CompilerType const*, unsigned int, bool, unsigned int)
This fix will ensure that all arguments to lldb_private::ClangASTContext::CreateFunctionType() are in order by checking:
- AST is valid
- if arguments are specified we have a valid argument array
- return type is valid
- return type is a clang type
- all argument types are valid
- all argument types are clang types
If any of these fail, we return an invalid CompilerType. If we don't return an invalid type, clang will crash anyway, and LLDB must not crash even in the presence of bad or missing debug info.
<rdar://problem/25172715>
llvm-svn: 270932
ClangASTContext::StartTagDeclarationDefinition(...) was starting definitions for any TagType instances that have TagDecl, but ClangASTContext::CompleteTagDeclarationDefinition(...) was getting the type to a CXXRecordDecl with:
clang::CXXRecordDecl *cxx_record_decl = qual_type->getAsCXXRecordDecl();
The problem is that getAsCXXRecordDecl() might dig a bit deeper into a type and dig out a different decl, which means we might call ClangASTContext::StartTagDeclarationDefinition(...), but it might not do anything, and then we might call ClangASTContext::CompleteTagDeclarationDefinition(...) and it might try to complete something that didn't have its definition started and this will crash.
This change fixes that, and also makes sure that starting a definition succeeds before any calls to ClangASTContext::CompleteTagDeclarationDefinition().
<rdar://problem/24091798>
llvm-svn: 270891
If users call "static void lldb::SBDebugger::Terminate()" we will clean up the debugger list, and users can individually destroy debugger instances with "static void lldb::SBDebugger::Destroy(SBDebugger &)". But if we let the C++ destructor chain tear down this list, other threads that might still be running as the main thread exits can now crash if they access the debugger list. We stop this by leaking the debugger list and its mutex.
<rdar://problem/26372169>
llvm-svn: 270869
Summary:
One can still use the LLVM variables to control this: LLVM_ENABLE_EH, LLVM_ENABLE_RTTI. It's not
clear to me why one would want to control these at lldb level and it's generally not even a good
idea to compile parts of the same binary with different values of these flags.
Reviewers: zturner, tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20673
llvm-svn: 270863
Summary:
Recent increase in the usage of std::weak_ptr has caused us to rediscover an issue in libstdc++
versions prior to 4.9 <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59656>, which make this class
unusable without exceptions in the presence of multiple threads. It's virtualy impossible to work
around this issue without implementing our own shared_ptr/weak_ptr substitutes, which does not
seem like a good idea.
Therefore, I am adding a big CMake warning which warns you about this issue if you're attempting
a to do a build which is suceptible to this problem and suggests possible alternatives. Right
now, nothing spectacular will happen if you ignore this warning (all the crashes I have seen
occur during process shutdown), but there's no guarantee the situation will not change in the
future.
Reviewers: tberghammer, tfiala, nitesh.jain, omjavaid, emaste, krytarowski
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20671
llvm-svn: 270854
This change adds the capability of building test inferiors
with the -gmodules flag to enable module debug info support.
Windows is excluded per @zturner.
Reviewers: granata.enrico, aprantl, zturner, labath
Subscribers: zturner, labath, lldb-commits
Differential Revision: http://reviews.llvm.org/D19998
llvm-svn: 270848
Summary:
This adds the ability to customize the debugserver codesign process via cmake cache variable. The
user can set the codesign indentity (with the default being the customary lldb_codesign), and if
the identity is set to a empty string, the codesign step is skipped completely.
We needed the last feature to enable building lldb on buildservers which do not have the right
certificates installed.
Reviewers: sas, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20623
llvm-svn: 270832
Greg Clayton