Thanks for the clarification @jrtc27.

As I already replied earlier, there is not enough context to reach the MachineFunction from the symbol or determine if relaxation is enabled for the given address range.

Remove unnecessary checks for relaxation flags in "target-features".

Created a virtual method in AsmPrinter instead of using MCSubtargetInfo::checkFeatures.

In D143645#4151098, @craig.topper wrote:

In D143645#4151078, @dblaikie wrote:

In D143645#4150034, @RamNalamothu wrote:

In D143645#4148087, @dblaikie wrote:

Is this new behavior visible through some existing non-test callers of MCSubtargetInfo::checkFeatures? Could that be tested using a lit-style test to demonstrate that this behavior is desirable/correct at that scope, beyond the narrower unit test?

Without this change, few lit tests will fail with the updated changeset for D140478. Would that be sufficient to showcase that this change is needed?

Could you walk me through that in more detail - oh, is that other patch checking for features in generic code on platforms/targets that don't support those features at all? Maybe that's a problem/the thing that should be fixed, and that other code should be moved to some target-specific hook?

That's what it looks like to me. I also think that some virtual methods a target can override would be a better way to solve this.

In D143645#4148087, @dblaikie wrote:

Is this new behavior visible through some existing non-test callers of MCSubtargetInfo::checkFeatures? Could that be tested using a lit-style test to demonstrate that this behavior is desirable/correct at that scope, beyond the narrower unit test?

Few lit tests will fail for using MCSubtargetInfo::checkFeatures without D143645.

Address review comments.

Ping.

Ping.

Thanks for the comments @dblaikie @craig.topper.

Address review comments.

In D140478#4011085, @dblaikie wrote:

Is there any mechanism that tests whether a given range bounded by two labels may be subject to linker relaxation? It'd be nice to have that abstraction and use it here (& in some other places in DWARF emission) rather than hardcoding one particular architecture.

Introduce an MCAsmInfo API to check if linker relaxation is enabled for generating relocatable symbol references.

Another attempt to fix the pre-merge check failure.

Fix the pre-merge checks test failure.

http://logan.tw/llvm/nounwind.html might be helpful in throwing some light on the problem being solved here.

Incorporated all the downstream changes.

Incorporated all the downstream changes.

Incorporated all the downstream changes.

Incorporated all the downstream changes.

Rebase onto LLVM mainline top of the tree.

Rebase onto LLVM top of the tree.

Rebase onto LLVM top of the tree.

Rebase onto LLVM top of the tree.

Address review comments.

I don't think there are any issues.

In D50304#3641971, @DavidSpickett wrote:

then we may need to find someone with an arm machine.

I tried this patch on AArch64 and did not get any new failures. You can go ahead and reland. If there's still issues I can help fix them.

Ping.

Make the test case insensitive to compiler optimizations.

In D50304#3611390, @goncharov wrote:

FYI this caused a test breakage at lldb-aarch64-ubuntu, https://lab.llvm.org/buildbot/#/builders/96/builds/25128. I have reverted this in fe6db8d03ff16a65f57af24d2cb04f489e2e9b0c

Thank you.

Sorry for spamming. But I am not sure if you have received my previous messages.

Ping.

In D50304#3586710, @jingham wrote:

For some reason I'm not getting mail notifications for review changes, sorry about that.

This is certainly better than the original implementation. Among other things, if we find an exact match, we really shouldn't be doing any more inexact matches, so after the first exact hit it should have switched exact to true.

But if you had line tables laid out like (this is in increasing order of address:

10
20
30
10
16

and you did "thread until 15", this would find the inexact match at 20, switch to an exact match for line 20 and find no other matches. But the gap between 10 & 16 in the line table is maybe an even more plausible place to put the line 15 until breakpoint, so maybe we did want to throw a breakpoint there as well?

@jingham
Nope, with the current patch, we would find the inexact match at 16.

@jingham looks like you missed to notice this one as well.

Address feedback.

Ping.

Ping.

Removed llvm/IR/Metadata.h header inclusion.

Address feedback.

Ping.

Ping.

Thank you @aprantl.

Address review feedback.

Thank you very much @djtodoro.

Ping.

Does this look good now to land?

Does this look good now to land?

Went ahead and added the error capturing for setting incorrect thread id and also the fix.

Added the test coverage.

I have tried to add a test but it's becoming difficult for me to come-up with a failing test scenario. Is it okay to commit this without a test?

Ping

Ping.

Ping

@djtodoro thanks for the quick response

Address feedback.

Could someone review/comment/approve this revision?

Rebase onto ToT.