Fast ISel isn't able to handle 'insertvalue' and it causes a large slowdown
during -O0 compilation. We don't necessarily need to generate an aggregate of
the values here if they're just going to be extracted directly afterwards.
<rdar://problem/10530851>
llvm-svn: 146481
Check that the pc value for frames up the stack is in a
mapped+executable region of memory.
Check that the stack pointer for frames up the stack is
in a mapped+readable region of memory.
If the unwinder ever makes a mistake walking the stack,
these checks will help to keep it from going too far into
the weeds.
These aren't fixing any bugs that I know of, but they
add extra robustness to a complicated task.
llvm-svn: 146478
if this is a mapped/executable region of memory. If it isn't, we've jumped
through a bad pointer and we know how to unwind the stack correctly based
on the ABI.
Previously I had 0x0 special cased but if you jumped to 0x2 on x86_64 one
frame would be skipped because the unwinder would try using the x86_64
ArchDefaultUnwindPlan which relied on the rbp.
Fixes <rdar://problem/10508291>
llvm-svn: 146477
test cases where there were a lot of relocations applied relative to a large
rodata section. Gas would create a symbol for each of these whereas we would
be relative to the beginning of the rodata section. This change mimics what
gas does.
Patch by Jack Carter.
llvm-svn: 146468
of the targets we know about. Because this is cached, rebuilds won't
detect when new targets show up. It's also a bit simpler to just say
"all". If users want to restrict the target set, they can still do so,
and then the cache will preserve what they have explicitly set this
field to.
llvm-svn: 146467
undefined result. This adds new ISD nodes for the new semantics,
selecting them when the LLVM intrinsic indicates that the undef behavior
is desired. The new nodes expand trivially to the old nodes, so targets
don't actually need to do anything to support these new nodes besides
indicating that they should be expanded. I've done this for all the
operand types that I could figure out for all the targets. Owners of
various targets, please review and let me know if any of these are
incorrect.
Note that the expand behavior is *conservatively correct*, and exactly
matches LLVM's current behavior with these operations. Ideally this
patch will not change behavior in any way. For example the regtest suite
finds the exact same instruction sequences coming out of the code
generator. That's why there are no new tests here -- all of this is
being exercised by the existing test suite.
Thanks to Duncan Sands for reviewing the various bits of this patch and
helping me get the wrinkles ironed out with expanding for each target.
Also thanks to Chris for clarifying through all the discussions that
this is indeed the approach he was looking for. That said, there are
likely still rough spots. Further review much appreciated.
llvm-svn: 146466
validates the "self," "this," and "_cmd" pointers
that get passed into expressions. It used to check
them aggressively for validity before allowing the
expression to run as an object method; now, this
functionality is gated by a bool and off by default.
Now the default is that when LLDB is stopped in a
method of a class, code entered using "expr" will
always masquerade as an instance method. If for
some reason "self," "this," or "_cmd" is unavailable
it will be reported as NULL. This may cause the
expression to crash if it relies on those pointers,
but for example getting the addresses of ivars will
now work as the user would expect.
llvm-svn: 146465
Modified the Xcode project to not strip liblldb-core.a for BuildAndIntegration builds
and to correctly strip only debug symbols from the command line binaries.
llvm-svn: 146462
Constant pool entries with different alignment may cause more alignment
padding to be inserted. Compute the amount of padding needed, and try to
pick the location that requires the least amount of padding.
Also take the extra padding into account when the water is above the
use.
llvm-svn: 146458
Necessary to parse Microsoft ATL code.
Example:
int array[] = {
0,
__if_exists(CLASS::Type) {2, }
3
};
will declare an array of 2 or 3 elements depending on if CLASS::Type exists or not.
llvm-svn: 146447
Kostya Serebryany