location where we're spelling a token even within a
macro. clang_getInstantiationLocation() tells where we instantiated
the macro.
I'm still not thrilled with the CXSourceLocation/CXSourceRange APIs,
since they gloss over macro-instantiation information.
Take 2: this time, adjusted tests appropriately and used a "simple"
approach to the spelling location.
llvm-svn: 118495
location where we're spelling a token even within a
macro. clang_getInstantiationLocation() tells where we instantiated
the macro.
I'm still not thrilled with the CXSourceLocation/CXSourceRange APIs,
since they gloss over macro-instantiation information.
llvm-svn: 118492
to not get resolved.
Fixed the "void **isa_ptr" variable inside the objective C verifier to start
with a '$' character so we don't go looking for it in our program.
Moved the lookup for "$__lldb_class" into the part that knows we are looking
for internal types that start with a '$'.
llvm-svn: 118488
I only did a tiny bit of testing; in the one case I tried changing the
contents of a radar in the middle of a stack and it was still current in
the live register context so it filtered down to frame 0 and was handed
over to the live register set RegisterContext. I need to test a case
where a register is saved on the stack in memory before I check this
one off.
llvm-svn: 118486
the frame count is requested or each frame is individually requested.
In practice this doesn't seem to help anything because we have
functions like StackFrameList::GetNumFrames() which is going to
request each frame anyway. And classes like ThreadPlanStepRange
and ThreadPlanStepOverRange get the stack depth in their ctor forcing
a full stack walk. But at least UnwindLLDB will delay doing a full
walk if it can.
llvm-svn: 118477
constant pool references and global variable refernces to resolve properly
for object file generation. For example,
int x;
void foo(unsigned a, unsigned *p) {
p[a] = x;
}
can now be successfully compiled directly to an (ARM mode) object file.
llvm-svn: 118469
FuncUnwinders object if the eh_frame section was missing
from an objfile. Worked fine on x86_64 but on i386 where
eh_frame is unusual, that resulted in the arch default
UnwindPlan being used all the time instead of picking up
an assembly profile based unwindplan.
llvm-svn: 118467
there's no return adjustment from the overridden to the overrider doesn't
mean there isn't a return adjustment from the overrider to the final
overrider. This matters if we're emitting a virtual this-adjustment thunk
because the overrider virtually inherits from the class providing the
nearest overridden method. Do the appropriate return adjustment in this case.
Fixes PR7611.
llvm-svn: 118466
Duncan Sands