SBAddress currently *may* have an Address object or it may not.
If it has an Address object, it is assumed to be Valid.
Change SBAddress to always have an Address object and check
whether it is valid or not in those case.

This is fixing a subtle problem where we ended up with
a SBAddress with an Address of LLDB_INVALID_ADDRESS could
run through a copy constructor and turn into an SBAddress
with no Address object being backed (because it wasn't
distinguishing between invalid-Address versus no-Address.)

The cost of an Address object is not high and this will be
an easy mistake for someone else to make; I'm fixing
SBAddress so it doesn't come up again.
<rdar://problem/18069407> 


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@221002 91177308-0d34-0410-b5e6-96231b3b80d8
Always transmit SIGPROF back to the inferior.

Summary:
SIGPROF is used for profiling processes (with google-perftools for
instance), which results in the inferior receiving a SIGPROF from the
kernel every few milliseconds. Instead of stopping the debugging session
and notifying the user of this, we should just pass the signal and keep
running.

This follows the behavior we have in UnixSignals.cpp.

Test Plan: Run LLDB on linux with a binary using google-perftools, see that execution gets interrupted all the time because we receive SIGPROF. Apply the patch, everything works fine.

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D5953

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@221011 91177308-0d34-0410-b5e6-96231b3b80d8
TOT broken by R220956 - Differential Revision: http://reviews/llvm.org/D6066

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@221018 91177308-0d34-0410-b5e6-96231b3b80d8