This change was reverted and hence causes LLDB AArch64 test failures again.

Thanks @clayborg suggestions noted and will be fixed in committed patch.

This rev breaks LLDB for AArch64. functionalities/thread/concurrent_events/* tests are failing after r368987.

Fixes typo in first rev.

This change breaks arm/aarch64 linux builds.

This was much needed. LGTM

LGTM

Hi I have updated diff with corrections.

This patch has following updates:

In D29669#670896, @clayborg wrote:

I would prefer to see NativeBreakpoint struct expanded to have more member variables instead of adding a new hardware breakpoint list. Then you just ask any breakpoint to enable/disable/remove itself and the structure contains all of the info we need. Keeping two lists means we have to check two lists. Let me know if any of my inline comments weren't clear?

I have added look up for dladdr and it works for android debug info build.

So I have given this a thought and have a inclination towards sticking to my first patch that was testing for following:

Guarding against HAVE_DLOPEN now. Works fine.

There is not exact solution that satisfies all corner cases. Abandoning for now until I come up with a solution that covers us from all corners.

Although this patch fixes the test case in question but in theory EphemeralMode watchpoint enable/disable cycles should be independent of step-over watchpoint enable disable cycle.

Sorry I was on Holiday so couldnt get back to this earlier.

@labath Referring to your email on the mailing list.

Give this approach a rethink I dont see a lot of problems with this final implementation unless it fails on other architectures.
We are already hacking our way to have these byte selection watchpoints working in existing code. New code seems to be improving the hack in my opinion.

This is a new version of what seems to me fully implementing functionality we intend to have here.

Answers to comments. I will upload a updated patch after corrections and updates.

I have added a new test case that tests suggested scnario without changing any previous test cases.

comments inline.

so I have used ?= now with following new changes

OBJCOPY ?= $(call replace_cc_with,objcopy)
ARCHIVER ?= $(call replace_cc_with,ar)
override AR = $(ARCHIVER)

I like your suggestions and I dont think we have any other way but to use preset environment variable to detect what kind of TOOLCHAIN we want to use apart from some standard cases where we have the ability to detect through proposed hack logic.

Updated with suggestion incorporated.

Adding context.

reopening this for new review.

I have updated previous patch which handles compiler binaries which have version string appended at the end like gcc-4.9 or clang-3.5.

Sorry about the delay updating this. I lost track of this rev earlier.

I am going ahead and committing this patch. If it breaks any build please revert it.

@clayborg
Any comments about this change? Thanks!

I have added a test cases that tests all possibilities supported by current configuration.

In D21280#457196, @labath wrote:

The overall change looks good, but please also add a test which specifically tests for watchpoints at unaligned addresses. Last time I checked, we all watchpoint tests were passing (at least on android) even without this patch, so it looks like our tests coverage is not sufficient here.

Seems to be causing no regressions on arm-linux.