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?

updated test .cpp source description with correct source.

In D49426#1165146, @dblaikie wrote:

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