control to the user anyway. This was put in to handle monitors that would say there was no
stop reason when you first attached to them. But it broke the case where you hit a thread specific
breakpoint on many threads, but NOT the one specified in the breakpoint. I work around this
by only doing the junky override when the StopID is 0 - i.e. on first attach.
This commit also adds a test for thread specific breakpoints.
llvm-svn: 199290
As done in other DW_OP_* cases, return an error if the stack is empty
rather than eventually crashing elsewhere. Encountered on big-endian
MIPS, where LLVM bugs currently result in invalid .debug_loc data.
llvm-svn: 199110
symbols correctly. There were a couple of pieces to this.
1) When a breakpoint location finds itself pointing to an Indirect symbol, when the site for it is created
it needs to resolve the symbol and actually set the site at its target.
2) Not all breakpoints want to do this (i.e. a straight address breakpoint should always set itself on the
specified address, so somem machinery was needed to specify that.
3) I added some info to the break list output for indirect symbols so you could see what was happening.
Also I made it clear when we re-route through re-exported symbols.
4) I moved ResolveIndirectFunction from ProcessPosix to Process since it works the exact same way on Mac OS X
and the other posix systems. If we find a platform that doesn't do it this way, they can override the
call in Process.
5) Fixed one bug in RunThreadPlan, if you were trying to run a thread plan after a "running" event had
been broadcast, the event coalescing would cause you to miss the ThreadPlan running event. So I added
a way to override the coalescing.
6) Made DynamicLoaderMacOSXDYLD::GetStepThroughTrampolinePlan handle Indirect & Re-exported symbols.
<rdar://problem/15280639>
llvm-svn: 198976
I previously fixed a bug in the SocketAddress class where SocketAddress::GetPort() wasn't using ntohs() on the port number in the structures.
After fixing this, it broke places where we weren't using ntohs() and htons() correctly.
<rdar://problem/15767514>
llvm-svn: 198902
210: test_with_dsym_and_run_command (Test-rdar-10642615.Radar10642615DataFormatterTestCase)
Test data formatter commands. ... Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file llvm/include/llvm/Support/Casting.h, line 239.
226: test_with_dsym_and_run_command (Test-rdar-13338477.Radar13338477DataFormatterTestCase)
Test that LLDB handles the clang typeclass Paren correctly. ... Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file llvm/include/llvm/Support/Casting.h, line 239.
llvm-svn: 198811
it is causing an llvm assert when run against
test/functionalities/data-formatter/rdar-10642615,
Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file llvm/include/llvm/Support/Casting.h, line 239.
llvm-svn: 198809
This change fixes a bug recently introduced in ProcessGDBRemote that
prevented the Python register definition file from getting loaded when
the qRegisterInfo0 response returned $00#.
Patch by Steve Pucci.
llvm-svn: 198742
When determining the type of array members, do not see-through typedefs
For instance, in BOOL arr[4], we want the elements to be typed as BOOL, not signed char
llvm-svn: 198729
materialize a variable in a register correctly
if the variable is a pointer. This fixes a
regression introduced by my commit of Oct. 22nd
(r193191).
llvm-svn: 198718
and EmulateInstructionARM::GetFramePointerDWARFRegisterNumber to recognize
the Apple arm convention (of using r7 for the frame pointer, regardless of
thumb or arm) even if the OS does not match Darwin/MacOSX/iOS. Also
corrects the behavior for thumb code on non-Apple platforms.
<rdar://problem/14661537>
llvm-svn: 198648
The former will set the Address object's offset to the load address value if
it is not present in any section; the latter will only set the Address object
if the load addr is contained in one of its sections.
<rdar://problem/15135987>
llvm-svn: 198469
its stack frame is a constructed, fake thing that may not conform
correctly to these rules. This fixes a problem where lldb couldn't
backtrace past an asynchronous signal handler (_sigtramp) frame on
a stack on Mac OS X.
<rdar://problem/15035673>
llvm-svn: 198450
The "type format add" command gets a new flag --type (-t). If you pass -t <sometype>, upon fetching the value for an object of your type,
LLDB will display it as-if it was of enumeration type <sometype>
This is useful in cases of non-contiguous enums where there are empty gaps of unspecified values, and as such one cannot type their variables as the enum type,
but users would still like to see them as-if they were of the enum type (e.g. DWARF field types with their user-reserved ranges)
The SB API has also been improved to handle both types of formats, and a test case is added
llvm-svn: 198105
interpret core files that contain both a user
process dyld and a kernel executable in them.
Fix an additional method that needs to be
adjusted depending on this preference as well.
<rdar://problem/15721409>
llvm-svn: 197931
TypeFormatImpl used to just wrap a Format (and Flags for matching), and then ValueObject itself would do the printing deed
With this checkin, the responsibility of generating a value string is centralized in the data formatter (as it should, and already is for summaries)
This change is good practice per se, and should also enable us to extend the type format mechanism in a cleaner way
llvm-svn: 197874
it needs to fall back to using the HostArchitecture if a valid one is not
returned. When doing low-level system debugging we may not have a process
(or the remote stub may not support the qProcessInfo packet) in which case
we should fall back to the architecture we determined via qHostInfo.
<rdar://problem/15713180>
llvm-svn: 197857
So, rename the class for what it truly is: a FormattersContainer
Also do a bunch of related text substitutions in the interest of overall naming clarity
llvm-svn: 197795
of Objective-C classes are completed, and that
variables of Objective-C types have their types
completed when the variables are reported.
This fixes a long-standing issue where ivars did
not show up correctly on 32-bit OS X.
<rdar://problem/12184093>
llvm-svn: 197775
specify a pointer size until code gen. So we just
make all our pointer-sized integer literals 64-bit.
That doesn't seem to hurt anything.
llvm-svn: 197774
The original code was not completely correct, but a form of
this check is necessary to avoid an infinite recursion on
some unwind cases where a function unwinds to itself with the
same CFA. Ashok thought the recursion would be caught in
RegisterContextLLDB but this one isn't - we still need it here.
<rdar://problem/15664282>
llvm-svn: 197761
In those set of patches, Ashok changed Module::ResolveSymbolContextForAddress
so that if it failed to find a symbol for a pc, it could back up
the pc value by 1 and re-search for a symbol.
His change to RegisterContextLLDB.cpp partially duplicates that
behavior but it also removes the separate case where we find a
Symbol for the pc address but it's the wrong symbol -- we need to
handle this as well as the lookup-by-pc-finds-no-symbol case.
The most obvious fallout from this regression was that lldb on
Mac OS X couldn't backtrace past __assert_rtn() which tail-calls
abort(). e.g.
(lldb) bt
* thread #1: tid = 0x5d6ea1, 0x00007fff8ee80866 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
* frame #0: 0x00007fff8ee80866 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x00007fff8eb5835c libsystem_pthread.dylib`pthread_kill + 92
frame #2: 0x00007fff8852ab1a libsystem_c.dylib`abort + 125
frame #3: 0x00007fff884f49bf libsystem_c.dylib`__assert_rtn + 321
frame #4: 0x0000000100000f2c a.out`main + 124
(lldb) dis -c 3 -s 0x7fff884f49b3
libsystem_c.dylib`__assert_rtn + 309:
0x7fff884f49b3: movq %rax, -0x11b96242(%rip) ; gCRAnnotations + 8
0x7fff884f49ba: callq 0x7fff8854fd2c ; symbol stub for: abort
libsystem_c.dylib`basename:
0x7fff884f49bf: pushq %rbp
(lldb)
in this case, __assert_rtn() is immediately followed by basename() and
the changes in r190812 didn't back up the pc value to get the correct
function name / unwind info.
<rdar://problem/15367233>
llvm-svn: 197655
