After hitting the malloc() breakpoint on FreeBSD our top frame is actually
an inlined function malloc_init.
* frame #0: 0x0000000800dcba19 libc.so.7`malloc [inlined] malloc_init at malloc.c:5397
frame #1: 0x0000000800dcba19 libc.so.7`malloc(size=1024) + 9 at malloc.c:5949
frame #2: 0x00000000004006e5 test_step_out_of_malloc_into_function_b_with_dwarf`b(val=1) + 37 at main2.cpp:29
Add a heuristic to keep stepping out until we come to a non-malloc caller,
before checking if it is our desired caller from the test code.
llvm.org/pr17944
llvm-svn: 203268
A freebsd issue with rm prevents '[g]make clean' from working if $(DSYM)
is empty (fts_open(3) fails if passed an empty argument).
To work around this, simplify the clean target by using three separate
rm invocations: one for the common files, one for the case of non-empty
$(DYLIB_NAME), and one for non-empty $(DSYM).
Issue diagnosed (and reported to FreeBSD) by John Wolfe.
llvm.org/pr17933
llvm-svn: 203253
not going to key off of the ELF object file like I'd intended.
Revert my change in r203205; also revert Greg's change in
r203107 which builds ProcessElfCore on non-Linux/FreeBSD systems
for the moment until we can straighten this out.
llvm-svn: 203207
ProcessMachCore because it doesn't check the format of the file up front. (this is only now
happening because of Greg's change in r203178 to build ProcessElfCore for non-Linux/FreeBSD
hosts).
<rdar://problem/16257533>
llvm-svn: 203205
It speeds up running the full test suite on my HP z620 Ubuntu machine with 32 hyperthreaded CPUs from 11 minutes to about 1m13s (about 9x).
The default behavior is to run single-threaded as before. If the environment variable LLDB_TEST_THREADS is set, a Python work queue is set up with that many worker threads.
To avoid collisions within a test directory where multiple tests make use of the same prebuilt executable, the unit of work for the worker threads is a single directory (that is, all tests within a directory are processed in the normal serial way by a single thread).
tfiala & I have run this way a number of times; the only issue I found was that the TestProcessAttach.py test failed once, when attempting to attach to the process "a.out" by name. I assume this is because some other thread was running an executable of that name at the same time, and we were attempting to attach to the wrong one, so I changed that test to use a different executable name (that change is also included in this commit).
llvm-svn: 203180
Author: ace2001ac
Date: Thu Mar 6 05:30:34 2014
New Revision: 203107
URL: http://llvm.org/viewvc/llvm-project?rev=203107&view=rev
Log:
Fix Windows build break introduced in r203035.
Add '#if defined(__linux__) || defined(__FreeBSD__)' around JITLoaderGDB
and ProcessElfCore, which are only built on Linux and FreeBSD.
Modified:
lldb/trunk/source/lldb.cpp
Windows will need to start building all files necessary so that JITLoaderGDB and ProcessElfCore can build since they should work on all platforms.
llvm-svn: 203178
Please do not add header files that are required in public APIs without first checking with us. This broke the LLDB builds at Apple because the lldb-dll-export.h wasn't included in the LLDB.framework and it was being included by public API header files.
llvm-svn: 203177
Add '#if defined(__linux__) || defined(__FreeBSD__)' around JITLoaderGDB
and ProcessElfCore, which are only built on Linux and FreeBSD.
llvm-svn: 203107
hold a strong pointer to that extended backtrace thread in the Process
just like we do for asking a thread's extended backtrace.
Also, give extended backtrace threads an invalid ThreadIndexID number.
We'll still give them valid thread_id's. Clients who want to know the
original thread's IndexID can call GetExtendedBacktraceOriginatingIndexID().
<rdar://problem/16126034>
llvm-svn: 203088
ProcessGDBRemote::GetAuxvData obtains the auxv from a remote gdbserver (via a binary-data packet), and returns the data as a DataBufferSP.
The patch includes a small fix to GDBRemoteCommunicationClient::SendPacketsAndConcatenateResponses() to support binary file format packet returns (by not assuming each binary packet is a null-terminated string when concatenating them).
llvm-svn: 202907
This change uses a fixed known offset for the Linux i386 DR0 register.
This change also undoes the 32-bit wordsize change from r169645 that
revolved around being 32-bit/64-bit friendly in
WriteRegOperation::Execute within the Linux ProcessMonitor.cpp. I ran
all the tests on x86_64 Linux with no failures. I also ran some simple
tests with 32-bit Linux exe on x86_64 host and 32-bit linux exe on
i686 32-bit host and these worked fine.
Note (from Todd): the UserData struct in the Linux i386 register
context (only used by Linux i386 host running Linux 32-bit inferior)
is out of sync with what shows up in the sys/user.h for an 32-bit
Linux build (per an earlier change of mine to make it look more like
x86_64 host running x86 exe). I think we should (1) make i386 Linux
targets run using the same register context (and correct ones) on i386
and x86_64 linux hosts if that is possible, and (2) we could use some
tests around the register handling, particularly to verify things like
DR0 registers are in the right spots on host/target combos that we can
verify vs. known correct values.
Change by Matthew Gardiner.
llvm-svn: 202887
The following two tests showed up as XFAIL even though they should
always be skipped on Linux, due to the @unittest2.expectedFailure
annotation appearing above the @dsym_test annotation:
TestObjCNewSyntax.ObjCNewSyntaxTestCase.test_expr_with_dsym
TestBlocks.BlocksTestCase.test_expr_with_dsym.
For those two, I simply moved the @dsym_test annotation to the top so
that it would be marked for skip ahead of being marked for XFAIL.
TestObjCNewSyntax.ObjCNewSyntaxTestCase.test_expr_with_dwarf I marked
as @skipIfLinux since my understanding is that isn't a valid test to
run on Linux. So rather than categorize as a fail (i.e. something
wrong to be fixed), just skip it. (My recent changes to Linux tests
have been following that model: if it could never work, skip; if it's
broken, mark XFAIL so we can easily track, fix, notice the fix and
adjust accordingly).
TestDeadStrip.DeadStripTestCase.test_with_dwarf I had previously
marked as XFAIL but this would never work on Linux with the current
linker AFAICT. Marked it as skip.
llvm-svn: 202788
Jason Molenda