LGTM but there's a small nit inline.

I have no idea. I discovered this issue while working on our internal 7.0 branch.

LGTM. This is just an updated version of D49407.

LGTM for now.

One idea I had was to introduce another target for the framwork itself, e.g. lldbFramework, which gets built if LLDB_BUILD_FRAMEWORK is set. It would depend on liblldb and all the necessary tools, headers, etc, that the framework would need. That way liblldb can depend only on what it needs to build instead of treating it as both the library and the entire framework. How do you feel about this?

Don't we risk creating circular dependencies with this? What happens when a tool depends on liblldb? you'll have theTool depend on liblldb and liblldb depend on theTool.

Review comments from @alexshap.

In D40539#937900, @clayborg wrote:

In D40539#937854, @sas wrote:

Basically, if you have a .debug directory in the same directory where the original object file is, you can have debug symbols there. For instance, you can have:

/my/project/myElf.exe
/my/project/.debug/myElf.exe

with the first file being a standard stripped elf file, and the second one being the associated debug symbols.

Do adding a FileSpec that contains just the basename will cause us to look for this file in the same directory as the original ELF file in the .debug folder?

In D40537#937880, @zturner wrote:

In D40537#937866, @sas wrote:

In D40537#937196, @zturner wrote:

You could use llvm's range adapters to make this slightly better.

auto Bytes = makeArrayRef(m_uuid, m_num_uuid_bytes);
return llvm::find(Bytes, 0) != Bytes.end();

Another option would just be return *this != UUID(m_num_uuid_bytes);

We want at least one non-zero element, we don't want a zero-element, so the proposed code wouldn't work. I'm not sure if there's an llvm utility that allows doing that directly without having to pass a lambda.

Wouldn't the other alternative work, where you just use operator== against a default constructed instance?

In D40537#937862, @clayborg wrote:

A better solution would be to initialize UUID::m_num_uuid_bytes with zero and only set it to a valid value if we set bytes into it. Then UUID::IsValid() becomes easy:

bool UUID::IsValid() const { return m_num_uuid_bytes > 0; }

This would allows us to actually have a UUID value that is valid and all zeroes. A few comments would need to be fixed as it currently assumes length is 16 or 20.

In D40537#937196, @zturner wrote:

You could use llvm's range adapters to make this slightly better.

auto Bytes = makeArrayRef(m_uuid, m_num_uuid_bytes);
return llvm::find(Bytes, 0) != Bytes.end();

Another option would just be return *this != UUID(m_num_uuid_bytes);

Basically, if you have a .debug directory in the same directory where the original object file is, you can have debug symbols there. For instance, you can have:

/my/project/myElf.exe
/my/project/.debug/myElf.exe

with the first file being a standard stripped elf file, and the second one being the associated debug symbols.

Address @zturner's comment and remove a useless temporary variable.

Friendly ping.

Move check out of if (TARGET clang) block.

Check only on Windows.

@davide: I agree, the extra dependency is annoying.

In D39315#908284, @zturner wrote:

So when you're using ds2 as the remote, are you still using the normal lldb test suite? dotest.py? If so, then we could have a test decorator that says @expectedFailure(not(debugserver=ds2)) or something. Then, even though you're the only one that can run it, at least YOU are sure it works. Some coverage is better than nothing. Is something like this possible?

In D39315#908251, @zturner wrote:

In D39315#908246, @sas wrote:

Same thing here, I have no idea how to go about testing something specific like this. Given that this is Windows Phone, it's even worse than simply Windows Desktop because the only way to test is by doing remote debugging. I suppose checking in binaries to the tree so we can analyze the symbols and ensure correctness is the only way to do it?

Do you guys not have access to Windows Desktops? It sounds like we need to get remote debugging of Windows targets working. I don't think I'm gonna be the one to do that in the near future, but if it's going to be a frequent thing that you're improving windows support for remote targets like Windows Phone, I imagine you're going to want the code to be tested, so hopefully you can convince someone to give you cycles to make remote debugging work properly, otherwise you're shipping untested code :-/

Same thing here, I have no idea how to go about testing something specific like this. Given that this is Windows Phone, it's even worse than simply Windows Desktop because the only way to test is by doing remote debugging. I suppose checking in binaries to the tree so we can analyze the symbols and ensure correctness is the only way to do it?

@clayborg: the follow-up to this change is in D39337, where we implement GetAddressClass().

In D19603#908130, @clayborg wrote:

Does this need some ARM support where we strip bit zero in case the entry point is Thumb?

Address comments by @clayborg.

I saw the bool is_arm = pattern only in ObjectFileMachO.cpp. I'm not sure about the specifics for Darwin targets, but having an object file with some functions in ARM and some functions in Thumb is valid, so I think checking for each symbol is the right thing to do.

In D39314#908065, @davide wrote:

can you please try adding a test for this one? :)

Rebase.

Indeed.