[DWARF] Fix handling of .debug_aranges with -g1

[ayermolo]

Summary

Old behavior was to add to .debug_aranges only when we create a DIE. As the
result we could end up in situation where DW_AT_ranges have addresses that are
not in .debug_aranges. This has caused issues for LLDB: D136395.

Changed it to add addresses to .debug_aranges even when DIE is not created.

[ayermolo]

nit

[clayborg]

Sounds reasonable to me, but I will let the llvm experts weigh in here. Even if we don't add a DW_TAG_subprogram, we might have line table addresses that are associated with source locations in a compile unit and we should map those addresses to the compile unit right?

[dblaikie]

This is the sort of thing I kind of wanted to avoid when we were talking about adding the aranges verifier - fixing bugs in aranges when instead we should be fixing bugs in consumers to not depend on aranges.

But anyway - if you really want/need aranges, perhaps a deeper fix would be good? We could emit aranges as CU ranges + data ranges instead of keeping an entirely separate list that can get out of sync? (& while we're at it, probably move the data ranges to the CU - rather than having to map them back from another independent data structure in DwarfDebug?)

llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp

2264

We're already in a DwarfDebug function, no need to retrieve the DwarfDebug object some other way.

[dblaikie]

Oh, also:

This has caused issues for LLDB

The debug_aranges verifier is mentioned as support for this statement, but I don't seee any discussion of LLDB in that thread - what's the connection to LLDB here? Could we fix LLDB to ignore aranges & just use CU ranges (which presumably it already does if aranges aren't present)?

[ayermolo]

In D137139#3899179, @dblaikie wrote:

This is the sort of thing I kind of wanted to avoid when we were talking about adding the aranges verifier - fixing bugs in aranges when instead we should be fixing bugs in consumers to not depend on aranges.

But anyway - if you really want/need aranges, perhaps a deeper fix would be good? We could emit aranges as CU ranges + data ranges instead of keeping an entirely separate list that can get out of sync? (& while we're at it, probably move the data ranges to the CU - rather than having to map them back from another independent data structure in DwarfDebug?)

I totally agree... Trying to see if we can migrate internal tool from using aranges. Although considering this is a bit of a "special case" with -g1, might be OK just let it be for that tool.

You have a good point. @clayborg can we just change lldb to ignore this section?

[clayborg]

In D137139#3900042, @ayermolo wrote:

In D137139#3899179, @dblaikie wrote:

This is the sort of thing I kind of wanted to avoid when we were talking about adding the aranges verifier - fixing bugs in aranges when instead we should be fixing bugs in consumers to not depend on aranges.

But anyway - if you really want/need aranges, perhaps a deeper fix would be good? We could emit aranges as CU ranges + data ranges instead of keeping an entirely separate list that can get out of sync? (& while we're at it, probably move the data ranges to the CU - rather than having to map them back from another independent data structure in DwarfDebug?)

I totally agree... Trying to see if we can migrate internal tool from using aranges. Although considering this is a bit of a "special case" with -g1, might be OK just let it be for that tool.

You have a good point. @clayborg can we just change lldb to ignore this section?

This is the first time I have been aware that .debug_aranges was so unreliable when we identified the root cause of this issue. I am totally fine and I will modify LLDB to ignore this section when it can. If we have valid indexes like .debug_names though, it would be a shame, if each compile unit doesn't have a DW_AT_ranges, to have to manually index the DWARF just to figure out the aranges for a compile unit, so I might let LLDB rely on this section if it is available, but only if the compile unit has no valid ranges.

We can modify every individual tool to work around the compiler producing a .debug_aranges section that doesn't do its job. That is certainly one way to fix this issue. I am also fine with giving up on .debug_aranges. In fact we should remove it completely from the compiler, as it isn't producing a section that any tool can rely on. Why are we even making it if we aren't going to do it right? And what is the with definition of doing it right, I think we have seen there are differences between what gcc and clang will produce. Part of this is the DWARF spec not . So yes I am fine with removing this section being used at all in LLDB. That still doesn't mean all of the other tools currently relying on it are going to work. So lets just stop the compiler from producing it all together, then no tools have to be modified so just magically know this section isn't reliable.

[clayborg]

I would also suggest that someone on the LLVM side make equivalent changes to make sure no one tries to use the .debug_aranges for the LLVM symbolizer in the DWARF code for LLVM, or for any DWARF code that does address lookups.

[JohnReagan]

I'll just point out that there are other debuggers/consumers of these sections besides lldb. I mostly just watch these code-changes with my bag of popcorn and pass them along to my debugger engineers.

[dblaikie]

In D137139#3900161, @clayborg wrote:

In D137139#3900042, @ayermolo wrote:

In D137139#3899179, @dblaikie wrote:

This is the sort of thing I kind of wanted to avoid when we were talking about adding the aranges verifier - fixing bugs in aranges when instead we should be fixing bugs in consumers to not depend on aranges.

But anyway - if you really want/need aranges, perhaps a deeper fix would be good? We could emit aranges as CU ranges + data ranges instead of keeping an entirely separate list that can get out of sync? (& while we're at it, probably move the data ranges to the CU - rather than having to map them back from another independent data structure in DwarfDebug?)

I totally agree... Trying to see if we can migrate internal tool from using aranges. Although considering this is a bit of a "special case" with -g1, might be OK just let it be for that tool.

You have a good point. @clayborg can we just change lldb to ignore this section?

This is the first time I have been aware that .debug_aranges was so unreliable when we identified the root cause of this issue. I am totally fine and I will modify LLDB to ignore this section when it can. If we have valid indexes like .debug_names though, it would be a shame, if each compile unit doesn't have a DW_AT_ranges, to have to manually index the DWARF just to figure out the aranges for a compile unit, so I might let LLDB rely on this section if it is available, but only if the compile unit has no valid ranges.

I agree in the abstract, but are there any producers you know of that don't produce CU ranges (& also do produce aranges) that this would be intended to support?

We can modify every individual tool to work around the compiler producing a .debug_aranges section that doesn't do its job. That is certainly one way to fix this issue. I am also fine with giving up on .debug_aranges. In fact we should remove it completely from the compiler, as it isn't producing a section that any tool can rely on. Why are we even making it if we aren't going to do it right? And what is the with definition of doing it right, I think we have seen there are differences between what gcc and clang will produce. Part of this is the DWARF spec not . So yes I am fine with removing this section being used at all in LLDB. That still doesn't mean all of the other tools currently relying on it are going to work. So lets just stop the compiler from producing it all together, then no tools have to be modified so just magically know this section isn't reliable.

I'd expect a lot of folks are "getting by" with what it is today and removing it entirely would be a regression for them. Perhaps they are having problems they don't realize - or perhaps it's "good enough" in that the bugs don't hurt them too much, or maybe don't hurt them at all (if they never use -gmlt + -garanges, for instance, maybe that's OK). Maybe we could thread the needle and remove aranges for gmlt, since gmlt is so focussed on debug info size, that might be worthwhile & anyone who comes complaining that their tool that relied on aranges is broken or slow we can say "well, the aranges in that case weren't correct anyway, so we've helped you, really".

Maybe that's a step along the deprecation/removal of aranges.

In D137139#3905592, @JohnReagan wrote:

I'll just point out that there are other debuggers/consumers of these sections besides lldb. I mostly just watch these code-changes with my bag of popcorn and pass them along to my debugger engineers.

Any ideas if your debugger relies on aranges? Do you also maintain a clang toolchain, does it default to emitting aranges (this isn't the default in trunk/upstream, but no doubt some people might change it for their situation/compatibility/whatever)?

[ayermolo]

addressed comment

[ayermolo]

Well this completely fell through the cracks. :facepalm
@dblaikie do you want to be an official reviewer for this?

[dblaikie]

In D137139#4078544, @ayermolo wrote:

Well this completely fell through the cracks. :facepalm
@dblaikie do you want to be an official reviewer for this?

Sure, don't mind formal or informal.

Was waiting on a few questions I asked @clayborg in my last comment. (perhaps the most practical one: Perhaps we could address this issue by removing support for aranges+gmlt instead of fixing this bug, as a step towards deprecating/removing aranges - though I'm not totally opposed to fixing the bug, just somewhat averse to supporting this use case where I think a bit more pressure on folks still using it to instead migrate to CU ranges might be good)

[ayermolo]

In D137139#4081739, @dblaikie wrote:

In D137139#4078544, @ayermolo wrote:

Well this completely fell through the cracks. :facepalm
@dblaikie do you want to be an official reviewer for this?

Sure, don't mind formal or informal.

Was waiting on a few questions I asked @clayborg in my last comment. (perhaps the most practical one: Perhaps we could address this issue by removing support for aranges+gmlt instead of fixing this bug, as a step towards deprecating/removing aranges - though I'm not totally opposed to fixing the bug, just somewhat averse to supporting this use case where I think a bit more pressure on folks still using it to instead migrate to CU ranges might be good)

Thank you. I'll ping Greg if he hasn't replied when he is back.
As for removing aranges, one of our internal symbolization tools relies on aranges currently. I don't think it's in the cards for that to change in short/medium future. :(

[clayborg]

In D137139#3905859, @dblaikie wrote:

In D137139#3900161, @clayborg wrote:

In D137139#3900042, @ayermolo wrote:

In D137139#3899179, @dblaikie wrote:

This is the sort of thing I kind of wanted to avoid when we were talking about adding the aranges verifier - fixing bugs in aranges when instead we should be fixing bugs in consumers to not depend on aranges.

But anyway - if you really want/need aranges, perhaps a deeper fix would be good? We could emit aranges as CU ranges + data ranges instead of keeping an entirely separate list that can get out of sync? (& while we're at it, probably move the data ranges to the CU - rather than having to map them back from another independent data structure in DwarfDebug?)

I totally agree... Trying to see if we can migrate internal tool from using aranges. Although considering this is a bit of a "special case" with -g1, might be OK just let it be for that tool.

You have a good point. @clayborg can we just change lldb to ignore this section?

This is the first time I have been aware that .debug_aranges was so unreliable when we identified the root cause of this issue. I am totally fine and I will modify LLDB to ignore this section when it can. If we have valid indexes like .debug_names though, it would be a shame, if each compile unit doesn't have a DW_AT_ranges, to have to manually index the DWARF just to figure out the aranges for a compile unit, so I might let LLDB rely on this section if it is available, but only if the compile unit has no valid ranges.

I agree in the abstract, but are there any producers you know of that don't produce CU ranges (& also do produce aranges) that this would be intended to support?

I don't try to guess what compilers people will use and then feed to LLDB. I just know I have seen it all over the years. Any even if we fix current tools to produce new and better output that is well suited to the debugger, we still need to be able to load anything we are given from the past.

We can modify every individual tool to work around the compiler producing a .debug_aranges section that doesn't do its job. That is certainly one way to fix this issue. I am also fine with giving up on .debug_aranges. In fact we should remove it completely from the compiler, as it isn't producing a section that any tool can rely on. Why are we even making it if we aren't going to do it right? And what is the with definition of doing it right, I think we have seen there are differences between what gcc and clang will produce. Part of this is the DWARF spec not . So yes I am fine with removing this section being used at all in LLDB. That still doesn't mean all of the other tools currently relying on it are going to work. So lets just stop the compiler from producing it all together, then no tools have to be modified so just magically know this section isn't reliable.

I'd expect a lot of folks are "getting by" with what it is today and removing it entirely would be a regression for them. Perhaps they are having problems they don't realize - or perhaps it's "good enough" in that the bugs don't hurt them too much, or maybe don't hurt them at all (if they never use -gmlt + -garanges, for instance, maybe that's OK). Maybe we could thread the needle and remove aranges for gmlt, since gmlt is so focussed on debug info size, that might be worthwhile & anyone who comes complaining that their tool that relied on aranges is broken or slow we can say "well, the aranges in that case weren't correct anyway, so we've helped you, really".

Maybe that's a step along the deprecation/removal of aranges.

By "gmlt" you mean "-g1"? LLDB is fine if this section is not here, so removing it anytime we can get away with it is fine.

The main issue is if we produce it, it should be reliable IMHO. AS you say, many people are relying on it, so anything we can do to fix it so that it is as correct as possible is a good thing.

[dblaikie]

In D137139#4083504, @clayborg wrote:

In D137139#3905859, @dblaikie wrote:

In D137139#3900161, @clayborg wrote:

In D137139#3900042, @ayermolo wrote:

In D137139#3899179, @dblaikie wrote:

This is the sort of thing I kind of wanted to avoid when we were talking about adding the aranges verifier - fixing bugs in aranges when instead we should be fixing bugs in consumers to not depend on aranges.

But anyway - if you really want/need aranges, perhaps a deeper fix would be good? We could emit aranges as CU ranges + data ranges instead of keeping an entirely separate list that can get out of sync? (& while we're at it, probably move the data ranges to the CU - rather than having to map them back from another independent data structure in DwarfDebug?)

I totally agree... Trying to see if we can migrate internal tool from using aranges. Although considering this is a bit of a "special case" with -g1, might be OK just let it be for that tool.

You have a good point. @clayborg can we just change lldb to ignore this section?

This is the first time I have been aware that .debug_aranges was so unreliable when we identified the root cause of this issue. I am totally fine and I will modify LLDB to ignore this section when it can. If we have valid indexes like .debug_names though, it would be a shame, if each compile unit doesn't have a DW_AT_ranges, to have to manually index the DWARF just to figure out the aranges for a compile unit, so I might let LLDB rely on this section if it is available, but only if the compile unit has no valid ranges.

I agree in the abstract, but are there any producers you know of that don't produce CU ranges (& also do produce aranges) that this would be intended to support?

I don't try to guess what compilers people will use and then feed to LLDB. I just know I have seen it all over the years. Any even if we fix current tools to produce new and better output that is well suited to the debugger, we still need to be able to load anything we are given from the past.

I think it'd be unfortunate to retain support for scenarios we have no evidence of - and in this particular case it'd just be worse performance to ignore aranges in the absence of CU ranges, not outright unsupported.

We can modify every individual tool to work around the compiler producing a .debug_aranges section that doesn't do its job. That is certainly one way to fix this issue. I am also fine with giving up on .debug_aranges. In fact we should remove it completely from the compiler, as it isn't producing a section that any tool can rely on. Why are we even making it if we aren't going to do it right? And what is the with definition of doing it right, I think we have seen there are differences between what gcc and clang will produce. Part of this is the DWARF spec not . So yes I am fine with removing this section being used at all in LLDB. That still doesn't mean all of the other tools currently relying on it are going to work. So lets just stop the compiler from producing it all together, then no tools have to be modified so just magically know this section isn't reliable.

I'd expect a lot of folks are "getting by" with what it is today and removing it entirely would be a regression for them. Perhaps they are having problems they don't realize - or perhaps it's "good enough" in that the bugs don't hurt them too much, or maybe don't hurt them at all (if they never use -gmlt + -garanges, for instance, maybe that's OK). Maybe we could thread the needle and remove aranges for gmlt, since gmlt is so focussed on debug info size, that might be worthwhile & anyone who comes complaining that their tool that relied on aranges is broken or slow we can say "well, the aranges in that case weren't correct anyway, so we've helped you, really".

Maybe that's a step along the deprecation/removal of aranges.

By "gmlt" you mean "-g1"?

Yep.

LLDB is fine if this section is not here, so removing it anytime we can get away with it is fine.

The main issue is if we produce it, it should be reliable IMHO. AS you say, many people are relying on it, so anything we can do to fix it so that it is as correct as possible is a good thing.

That's my suggestion, though - one way we could address the bug with -g1+-garanges is to not support that combination/reject it/not emit aranges under -g1.

But if you've really got tools that ignore CU ranges that are significantly harder to change than fixing clang/llvm here - I guess we can fix llvm... But I'd /really/ encourage folks to push towards removing dependence on aranges whenever possible/practical.

[clayborg]

If the only time clang is not emitting .debug_aranges correctly is when we use -g1, then fixing that issue (by either fixing or removing .debug_arnages) would be fine by me. That being said, we have a clang that has been producing bad .debug_aranges, so unless we fix LLDB it won't fix the issue for binaries already out in the wild.

[dblaikie]

In D137139#4084468, @clayborg wrote:

If the only time clang is not emitting .debug_aranges correctly is when we use -g1, then fixing that issue (by either fixing or removing .debug_arnages) would be fine by me. That being said, we have a clang that has been producing bad .debug_aranges, so unless we fix LLDB it won't fix the issue for binaries already out in the wild.

What sort of fix for LLDB are you picturing? One way to fix LLDB would be to teach it to ignore .debug_aranges - which would hurt perf on inputs with correct .debug_aranges but no CU ranges, but we don't seem to have anyone clamouring for support for that scenario.

[clayborg]

In D137139#4084505, @dblaikie wrote:

In D137139#4084468, @clayborg wrote:

If the only time clang is not emitting .debug_aranges correctly is when we use -g1, then fixing that issue (by either fixing or removing .debug_arnages) would be fine by me. That being said, we have a clang that has been producing bad .debug_aranges, so unless we fix LLDB it won't fix the issue for binaries already out in the wild.

What sort of fix for LLDB are you picturing? One way to fix LLDB would be to teach it to ignore .debug_aranges - which would hurt perf on inputs with correct .debug_aranges but no CU ranges, but we don't seem to have anyone clamouring for support for that scenario.

If I did a fix I would:

• use CU ranges always if they are available
• fall back to .debug_aranges if there
• do expensive manual parsing for ranges

[dblaikie]

In D137139#4087260, @clayborg wrote:

In D137139#4084505, @dblaikie wrote:

In D137139#4084468, @clayborg wrote:

If the only time clang is not emitting .debug_aranges correctly is when we use -g1, then fixing that issue (by either fixing or removing .debug_arnages) would be fine by me. That being said, we have a clang that has been producing bad .debug_aranges, so unless we fix LLDB it won't fix the issue for binaries already out in the wild.

What sort of fix for LLDB are you picturing? One way to fix LLDB would be to teach it to ignore .debug_aranges - which would hurt perf on inputs with correct .debug_aranges but no CU ranges, but we don't seem to have anyone clamouring for support for that scenario.

If I did a fix I would:

• use CU ranges always if they are available
• fall back to .debug_aranges if there
• do expensive manual parsing for ranges

That still doesn't address the existing broken aranges though, yeah? So to make LLDB robust to existing debug info, the only correct thing would be to ignore aranges - and we don't have any known examples where this hurts performance anyway (no known aranges-but-no-cu-ranges emitters), so seems like a pretty painless thing to do?

[ayermolo]

To me it sounds it's easier to just fix it in llvm, no?

[dblaikie]

In D137139#4090779, @ayermolo wrote:

To me it sounds it's easier to just fix it in llvm, no?

Though that doesn't address the concern @clayborg that lldb will still misbehave on existing compiled code?

[clayborg]

In D137139#4091380, @dblaikie wrote:

In D137139#4090779, @ayermolo wrote:

To me it sounds it's easier to just fix it in llvm, no?

Though that doesn't address the concern @clayborg that lldb will still misbehave on existing compiled code?

Which is ok, this is to fix the compiler. I can make separate LLDB changes to address the reality of the situation.

[dblaikie]

In D137139#4091399, @clayborg wrote:

In D137139#4091380, @dblaikie wrote:

In D137139#4090779, @ayermolo wrote:

To me it sounds it's easier to just fix it in llvm, no?

Though that doesn't address the concern @clayborg that lldb will still misbehave on existing compiled code?

Which is ok, this is to fix the compiler. I can make separate LLDB changes to address the reality of the situation.

What sort of change to LLDB are you thinking of?

[clayborg]

In D137139#4091496, @dblaikie wrote:

In D137139#4091399, @clayborg wrote:

In D137139#4091380, @dblaikie wrote:

In D137139#4090779, @ayermolo wrote:

To me it sounds it's easier to just fix it in llvm, no?

Though that doesn't address the concern @clayborg that lldb will still misbehave on existing compiled code?

Which is ok, this is to fix the compiler. I can make separate LLDB changes to address the reality of the situation.

What sort of change to LLDB are you thinking of?

using DW_AT_ranges instead of .debug_aranges if they are available.

[dblaikie]

In D137139#4091500, @clayborg wrote:

In D137139#4091496, @dblaikie wrote:

In D137139#4091399, @clayborg wrote:

In D137139#4091380, @dblaikie wrote:

In D137139#4090779, @ayermolo wrote:

To me it sounds it's easier to just fix it in llvm, no?

Though that doesn't address the concern @clayborg that lldb will still misbehave on existing compiled code?

Which is ok, this is to fix the compiler. I can make separate LLDB changes to address the reality of the situation.

What sort of change to LLDB are you thinking of?

using DW_AT_ranges instead of .debug_aranges if they are available.

So then LLDB wouldn't use this .debug_aranges data this patch fixes, right? So could we remove this .debug_aranges data instead?

[clayborg]

In D137139#4091685, @dblaikie wrote:

In D137139#4091500, @clayborg wrote:

In D137139#4091496, @dblaikie wrote:

In D137139#4091399, @clayborg wrote:

In D137139#4091380, @dblaikie wrote:

In D137139#4090779, @ayermolo wrote:

To me it sounds it's easier to just fix it in llvm, no?

Though that doesn't address the concern @clayborg that lldb will still misbehave on existing compiled code?

Which is ok, this is to fix the compiler. I can make separate LLDB changes to address the reality of the situation.

What sort of change to LLDB are you thinking of?

using DW_AT_ranges instead of .debug_aranges if they are available.

So then LLDB wouldn't use this .debug_aranges data this patch fixes, right? So could we remove this .debug_aranges data instead?

Older LLDB versions which are out in the wild and will exist until the end of time will use the .debug_aranges. So I would vote to fix the compiler and do it with this patch.

[dblaikie]

In D137139#4092255, @clayborg wrote:

In D137139#4091685, @dblaikie wrote:

In D137139#4091500, @clayborg wrote:

In D137139#4091496, @dblaikie wrote:

In D137139#4091399, @clayborg wrote:

In D137139#4091380, @dblaikie wrote:

In D137139#4090779, @ayermolo wrote:

To me it sounds it's easier to just fix it in llvm, no?

Though that doesn't address the concern @clayborg that lldb will still misbehave on existing compiled code?

Which is ok, this is to fix the compiler. I can make separate LLDB changes to address the reality of the situation.

What sort of change to LLDB are you thinking of?

using DW_AT_ranges instead of .debug_aranges if they are available.

So then LLDB wouldn't use this .debug_aranges data this patch fixes, right? So could we remove this .debug_aranges data instead?

Older LLDB versions which are out in the wild and will exist until the end of time will use the .debug_aranges. So I would vote to fix the compiler and do it with this patch.

They won't use them if we remove them. Old debug info in old lldb will always be broken, can't help there. Yes, we could fix or remove aranges and that'd fix new code in new or old lldb and we could change the priority (CU ranges first, then aranges) or remove aranges support from lldb and that'd fix new lldb with old and new code.

I'd prefer we move in a direction away from aranges.

But sure, feel free to make this fix - but I'd really encourage you to revisit your use of/need for aranges.

[ayermolo]

Thank you for reviewing and feedback.

llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp

for (const auto &R : Asm->MBBSectionRanges)
     TheCU.addRange({R.second.BeginLabel, R.second.EndLabel});
 
   // Under -gmlt, skip building the subprogram if there are no inlined
   // subroutines inside it. But with -fdebug-info-for-profiling, the subprogram
   // is still needed as we need its source location.
   if (!TheCU.getCUNode()->getDebugInfoForProfiling() &&
       TheCU.getCUNode()->getEmissionKind() == DICompileUnit::LineTablesOnly &&
       LScopes.getAbstractScopesList().empty() && !IsDarwin) {
+    for (const auto &R : Asm->MBBSectionRanges)
+      addArangeLabel(SymbolCU(&TheCU, R.second.BeginLabel));
+
     assert(InfoHolder.getScopeVariables().empty());
     PrevLabel = nullptr;
     CurFn = nullptr;
     return;
   }
 
 #ifndef NDEBUG
   size_t NumAbstractScopes = LScopes.getAbstractScopesList().size();

llvm/test/DebugInfo/X86/dwarf-aranges-g1.ll

+; REQUIRES: system-linux
+; RUN: llc -O0 --function-sections --generate-arange-section -filetype=obj %s -o %tmain.obj
+; RUN: llvm-dwarfdump --debug-info %tmain.obj > %tmain.txt
+; RUN: llvm-dwarfdump --debug-aranges %tmain.obj >> %tmain.txt
+; RUN: cat %tmain.txt | FileCheck --check-prefix=CHECK %s
+
+; CHECK: DW_AT_ranges
+; CHECK-NEXT: [0x[[#%.16x,ADDR:]], 0x[[#%.16x,ADDR1:]])
+; CHECK-NEXT: [0x[[#%.16x,ADDR2:]], 0x[[#%.16x,ADDR3:]])
+; CHECK-NEXT: [0x[[#%.16x,ADDR4:]], 0x[[#%.16x,ADDR5:]])
+
+; CHECK: Address Range Header
+; CHECK-NEXT: [0x[[#ADDR]], 0x[[#ADDR1]])
+; CHECK-NEXT: [0x[[#ADDR2]], 0x[[#ADDR3]])
+; CHECK-NEXT: [0x[[#ADDR4]], 0x[[#ADDR5]])
+
+; ModuleID = 'example.cpp'
+source_filename = "example.cpp"
+target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+%struct.S = type { ptr }
+
+@GlobalConst = dso_local global i32 42, align 4
+@Global = dso_local global i32 0, align 4
+@s = dso_local global %struct.S zeroinitializer, align 8
+
+; Function Attrs: alwaysinline mustprogress nounwind uwtable
+define dso_local noundef i32 @_Z6squarei(i32 noundef %i) #0 !dbg !10 {
+entry:
+  %i.addr = alloca i32, align 4
+  store i32 %i, ptr %i.addr, align 4
+  %0 = load i32, ptr %i.addr, align 4, !dbg !13
+  %1 = load i32, ptr %i.addr, align 4, !dbg !14
+  %mul = mul nsw i32 %0, %1, !dbg !15
+  ret i32 %mul, !dbg !16
+}
+
+; Function Attrs: mustprogress noinline nounwind optnone uwtable
+define dso_local noundef i32 @_Z4cubei(i32 noundef %i) #1 !dbg !17 {
+entry:
+  %i.addr.i = alloca i32, align 4
+  %i.addr = alloca i32, align 4
+  %squared = alloca i32, align 4
+  store i32 %i, ptr %i.addr, align 4
+  %0 = load i32, ptr %i.addr, align 4, !dbg !18
+  store i32 %0, ptr %i.addr.i, align 4
+  %1 = load i32, ptr %i.addr.i, align 4, !dbg !19
+  %2 = load i32, ptr %i.addr.i, align 4, !dbg !21
+  %mul.i = mul nsw i32 %1, %2, !dbg !22
+  store i32 %mul.i, ptr %squared, align 4, !dbg !23
+  %3 = load i32, ptr %squared, align 4, !dbg !24
+  %4 = load i32, ptr %i.addr, align 4, !dbg !25
+  %mul = mul nsw i32 %3, %4, !dbg !26
+  ret i32 %mul, !dbg !27
+}
+
+; Function Attrs: mustprogress noinline norecurse nounwind optnone uwtable
+define dso_local noundef i32 @main() #2 !dbg !28 {
+entry:
+  %retval = alloca i32, align 4
+  store i32 0, ptr %retval, align 4
+  ret i32 0, !dbg !29
+}
+
+attributes #0 = { alwaysinline mustprogress nounwind uwtable "frame-pointer"="all" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }
+attributes #1 = { mustprogress noinline nounwind optnone uwtable "frame-pointer"="all" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }
+attributes #2 = { mustprogress noinline norecurse nounwind optnone uwtable "frame-pointer"="all" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!2, !3, !4, !5, !6, !7, !8}
+!llvm.ident = !{!9}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14, file: !1, producer: "clang version 16.0.0 (ssh://git.vip.facebook.com/data/gitrepos/osmeta/external/llvm-project a312c5cce360203b4b24757e1e69738f8b3f2ec1)", isOptimized: false, runtimeVersion: 0, emissionKind: LineTablesOnly, splitDebugInlining: false, nameTableKind: None)
+!1 = !DIFile(filename: "example.cpp", directory: "/examples")
+!2 = !{i32 7, !"Dwarf Version", i32 4}
+!3 = !{i32 2, !"Debug Info Version", i32 3}
+!4 = !{i32 1, !"wchar_size", i32 4}
+!5 = !{i32 8, !"PIC Level", i32 2}
+!6 = !{i32 7, !"PIE Level", i32 2}
+!7 = !{i32 7, !"uwtable", i32 2}
+!8 = !{i32 7, !"frame-pointer", i32 2}
+!9 = !{!"clang version 16.0.0"}
+!10 = distinct !DISubprogram(name: "square", scope: !1, file: !1, line: 11, type: !11, scopeLine: 11, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !12)
+!11 = !DISubroutineType(types: !12)
+!12 = !{}
+!13 = !DILocation(line: 11, column: 59, scope: !10)
+!14 = !DILocation(line: 11, column: 63, scope: !10)
+!15 = !DILocation(line: 11, column: 61, scope: !10)
+!16 = !DILocation(line: 11, column: 52, scope: !10)
+!17 = distinct !DISubprogram(name: "cube", scope: !1, file: !1, line: 12, type: !11, scopeLine: 12, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !12)
+!18 = !DILocation(line: 13, column: 24, scope: !17)
+!19 = !DILocation(line: 11, column: 59, scope: !10, inlinedAt: !20)
+!20 = distinct !DILocation(line: 13, column: 17, scope: !17)
+!21 = !DILocation(line: 11, column: 63, scope: !10, inlinedAt: !20)
+!22 = !DILocation(line: 11, column: 61, scope: !10, inlinedAt: !20)
+!23 = !DILocation(line: 13, column: 7, scope: !17)
+!24 = !DILocation(line: 14, column: 10, scope: !17)
+!25 = !DILocation(line: 14, column: 18, scope: !17)
+!26 = !DILocation(line: 14, column: 17, scope: !17)
+!27 = !DILocation(line: 14, column: 3, scope: !17)
+!28 = distinct !DISubprogram(name: "main", scope: !1, file: !1, line: 17, type: !11, scopeLine: 17, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !12)
+!29 = !DILocation(line: 18, column: 3, scope: !28)