I've also added an internal ticket to add darwin support to the dexter regression suite... I don't think there'll be much appetite in-house for it but if there's a clear need to add it in the future then of course we'll consider putting in the work.

Hi Davide,

I've actually mailed these via the mailing list by accident, here's a copy of what I mailed:

@Pierre-vh and not a problem buddy, I wish you all the best in your future endeavours, don't worry about feedback on the controller patch if it's not related to your current work! :) you get on with what you need to.

The debugger controller patch is now live and awaiting review at

I hope you're keeping safe in these unprecedented times!

Hi Pierre,

I haven't attempted to generalize my work as I entirely rely on the LLDB library for this (and I work on Linux so I can't work with any other debugger supported by Dexter)
Maybe we can try to find something together? Where do you wish to discuss this?

Hi Pierre,

LGTM

Hi Reid,

Hi David,

KILL instruction is no reinstated and failing check line has been removed.

I missed adding you as a reviewer @djtodoro , my apologies. This has been rectified.

Hello Everyone,

I'll land this tomorrow as I'm off home now and don't want to risk getting buildbot emails all night.

updated diff

addressed further feedback

address feedback

thank you all for your valuable time.

Added isMetaInstruction() Check in place of debug intrinsic and KILL check
Added a new comment explaining why this is safe to do.

Thanks for explaining, this makes sense to me. Any reason to not use MI.isMetaInstruction() as the guard? That would cause CFI/lifetime/EH_LABEL instructions to be skipped in addition to debug/kill instructions - would that be reasonable?

removed unused declarations for stack protection.

removed vendor specific string from debug information

Added a comment to the KILL instruction check.

Apologies for the lack lustre description and vagueness of all this. Also, this is late coming due to sickness. My deepest and humblest apologies. Hope this clear things up though! enjoy.

not a problem gents, I've been summarising my thoughts and triple checking to make sure this is a sound thing to do and have a response with updated patch and (hopefully) additional tests incoming shortly.

A very gentle and polite ping.

thanks for the patch!

removed superflous attributes from function declarations.

Thanks David, it was quickly pointed out to me internally that there's a better place for the check so I rushed to get a quick build and test done before updating.

moved Kill instruction check to a more relevant place

some super nits. Patch is huge and difficult to parse, will require several passes I feel.

updated to use newly added helper function for salvage or undeffing behaviour when dropping instructions in reassociate expressions pass.

In D69943#1736998, @dstenb wrote:

If D69809 lands before this patch, then you can use the helper function salvageDebugInfoOrMarkUndef() which the former introduces.

Hi there,

Hi there!

Slight fix r351820 seems to have done the trick, many thanks!

and thanks for the patch either way, nice to know we're not in this alone.

seems like the best thing to do here is revert the original commit that broke the bots in the first place?

Hi there,

very gentle and polite ping.

No problem's David,

So, I've been poking around in MCObjectStreamer.cpp and have found the area where multiple .loc directives are emitted, however,

I've also taken a look at GAS and tested it's behaviour and have found it mirrors clangs, that is, it will happily output line entries for multiple .loc directives with no interceding instructions - thus leading to line table entries with address delta's of 0.

Hello fellow LLVM contributors.

Oh, I don't have commit access, are you able to commit for me Sam?

I'm happy as is.

The test failed on the following build bot:

couple of nitpicks.

In D49426#1166190, @CarlosAlbertoEnciso wrote:

In D49426#1165346, @TWeaver wrote:

In D49426#1165146, @dblaikie wrote:

Could you provide a small example dump of the invalid line table you're addressing?

I fed the resulting .elf into dwarfdump with -l and got the following output:

What is the ouput generated by llvm-dwarfdump?

In D49426#1165555, @dblaikie wrote:

I feel like maybe the solution here should be in the MC integrated
assembler - to not emit zero-length sequences in the line table, regardless
of whether it's in the prologue or anywhere else?