In D71372#1813703, @labath wrote:

In D71372#1813142, @ted wrote:

In D71372#1811594, @labath wrote:

In D71372#1810687, @ted wrote:

I've got another failure case for this. If the remote gdbserver doesn't implement qMemoryRegionInfo or qXfer:memory-map:read, thread step-out will fail.
....

That's a good point Ted. I think we should give targets which don't support fetching permissions the benefit of the doubt, and treat all memory as potentially executable. Would removing the return statement from the if(!GetLoadAddressPermissions) branch solve your problem? If so, can you whip up a patch for that?

Removing the return statement fixes the issue. I'll put up a patch. Keeping the m_constructor_errors.Printf line doesn't cause a failure; it might be useful to keep that in case the breakpoint can't be created for other reasons. What do you think?

I don't care much either way.. Since you have this kind of a target around, you can judge whether printing this error/warning after each "finish" would be useful or just annoying. Another possibility would be to don't print the error to the command output, but still emit something into the log...

In D71372#1811594, @labath wrote:

In D71372#1810687, @ted wrote:

I've got another failure case for this. If the remote gdbserver doesn't implement qMemoryRegionInfo or qXfer:memory-map:read, thread step-out will fail.
....

That's a good point Ted. I think we should give targets which don't support fetching permissions the benefit of the doubt, and treat all memory as potentially executable. Would removing the return statement from the if(!GetLoadAddressPermissions) branch solve your problem? If so, can you whip up a patch for that?

I've got another failure case for this. If the remote gdbserver doesn't implement qMemoryRegionInfo or qXfer:memory-map:read, thread step-out will fail.

llvm/tools/lldb/tools/driver/Driver.cpp:495:12: error: comparison of integers of different signs: 'ssize_t' (aka 'long') and 'size_t' (aka 'unsigned long') [-Werror,-Wsign-compare]

if (nrwr != commands_size) {
    ~~~~ ^  ~~~~~~~~~~~~~

1 error generated.

This doesn't look correct to me - it looks like there are 1 too many #endifs. I think the one at line 179 should be removed - it should have been replaced by the #else that is at line 180.

In D57552#1381126, @jingham wrote:

That sounds like it will have to be fixed somewhere else, and not part of this patch then. Can you file a bug to get that fixed?

In D57552#1381046, @jingham wrote:

In D57552#1380782, @ted wrote:

FYI, @jingham , this is also an issue with DYLD plugins, if the file in the link map starts with ".". "image search-paths add . /path/to/my/libraries" fails in this case, because "./library.so" gets changed to "library.so".

This should fix that issue as well, since image search-paths are also PathMappingLists. I don't see any tests for this, however. Do you have something handy you could turn into a test?

@sgraenitz I've found an issue with this patch, using the Visual Studio 2015 generator.

FYI, @jingham , this is also an issue with DYLD plugins, if the file in the link map starts with ".".

Another issue:

Added a test to TestAddressBreakpoints.py that sets an address breakpoint before launch, launches, and checks to see if the breakpoint was hit.

Yes, I'll add a new test to TestAddressBreakpoints.py.

@JDevlieghere I'm seeing the same issue as @alberto_magni . The Visual Studio cmake generator gives errors. We're reverting it internally, but it needs to be fixed or reverted ASAP.

In D39967#1017754, @labath wrote:

I believe lldb-server does not work around breakpoint opcodes during writing (it does for reading), but that can be fixed, of course.

Traditionally, remote gdbservers handle memory operations that overlap a software breakpoint. Writes get the new value saved off, and reads get the breakpoint opcode replaced by the saved value.

Thanks for adding me, Pavel.

We build lldb, clang and tools for Hexagon only, and call them hexagon-lldb, hexagon-clang, etc. The test infrastructure is smart enough to pick up hexagon-lldb-mi if we tell it to run with hexagon-lldb using --executable; will it be smart enough to run an in-tree hexagon-clang?

Tested with clang 3.8 on top-of-tree lldb-mi on Ubuntu 14.

We want to go down into a pointer if it's the original parent, but not into a child that's a pointer. To avoid skipping children of a top-level pointer/reference, I think we need to do the type check in the loop.

Updated with Greg's suggestion.

Added check for reference types, as Greg suggested.

I'm seeing the same issue as Nitesh, except in a different spot. The Hexagon Simulator doesn't support QSaveRegisterState, so lldb calls GDBRemoteRegisterContext::ReadAllRegisterValues. It gets a lock on the communication client, then calls ReadAllRegisters, which tries to get a lock on the communication client, and fails (hangs on Linux, crashes on Windows).

The problem this scenario has is asynchronous output from 2 different sources. The original fix made Windows (or any lldb without libedit) much better, but I think most non-Windows builds will use libedit, because it's extremely useful. lldb-mi has a different set of constraints; the position of the prompt isn't as important, since users won't use it as a cue to tell when the debugger can accept more input.

The Hexagon platform (currently in-house only) acts like the ios simulator platform, in that it doesn't connect - it fixes up the command line, then launches the Hexagon simulator (based on the debugserver launch code in the gdb-remote process plugin).

Addressed Jim's comments.

Problem will be fixed in another way.

Thanks for adding me, Tamas.

Adrian and I worked out what is going on:

Updated to change cursor position before async output so old prompt is overwritten.

Without the patch I'm seeing the original prompt printed after the command, in a line like this:

Updated to address Jim's comments.

So you'd like to see this function get the address of a function that it
finds in either symbols or debug info?

The change is to guard against the case where candidate_sc.symbol is nullptr.

Updated to use early-out as requested

Updated to address Sean's comments

Updated to check for invalid register numbers.

Handled by another patch

I tried deleting the target and setting the platform to the host platform at the end of the test in TestDisassemble_VST1_64.py, but that didn't solve the problem.

The problem with this test is it gets python in a bad state, so after it's run, all tests after error out. It runs fine on its own, but something like:
dotest.py python_api/

The error also happens on Linux; this test should be turned off everywhere.

My guess is the target create is failing. This line in the test:

This is essentially reverting http://reviews.llvm.org/rL237053 , so we'd go back to the problem with it - LLDB won't be able to set the platform based on the architecture in the target binary, but will use the currently selected platform, even if it's not compatible.

In D11129#203583, @tberghammer wrote:

I agree that the current implementation is annoying with using the platform selected at target creation time, but changing the platform for a target after it is created might be dangerous because it can cache information from the platform.

This codepath also fixes mangling issues with Hexagon binaries. Please add

|| (arch.GetTriple().GetMachine() == llvm::Triple::hexagon)

to the if, to pick up the fix for Hexagon.

LGTM