David Blaikie
2013-Dec-09 17:47 UTC
[LLVMdev] DebugInfo: DW_AT_GNU_ranges_base in non-fission
It looks like we only attach the GNU_ranges_base to skeleton CUs, and never use the attribute under non-fission. Is that right? It's not obvious to me why we'd want to only include this under fission, but I admittedly don't fully understand it anyway. - Dave
Eric Christopher
2013-Dec-09 19:48 UTC
[LLVMdev] DebugInfo: DW_AT_GNU_ranges_base in non-fission
On Mon, Dec 9, 2013 at 9:47 AM, David Blaikie <dblaikie at gmail.com> wrote:> It looks like we only attach the GNU_ranges_base to skeleton CUs, and > never use the attribute under non-fission. Is that right? It's not > obvious to me why we'd want to only include this under fission, but I > admittedly don't fully understand it anyway. >So we're not particularly using it correctly at the moment (given that it was relatively undocumented and I had word of mouth when implementing it), but the basic idea is that relocations to the range sections will be based off of a single relocation rather than have a bunch of them. It's not necessarily fission only, but it hasn't been standardized yet and is a bit of an experiment and still undergoing revision. I can disable it/command line if you think that's appropriate as well. -eric
David Blaikie
2013-Dec-09 20:01 UTC
[LLVMdev] DebugInfo: DW_AT_GNU_ranges_base in non-fission
On Mon, Dec 9, 2013 at 11:48 AM, Eric Christopher <echristo at gmail.com> wrote:> On Mon, Dec 9, 2013 at 9:47 AM, David Blaikie <dblaikie at gmail.com> wrote: >> It looks like we only attach the GNU_ranges_base to skeleton CUs, and >> never use the attribute under non-fission. Is that right? It's not >> obvious to me why we'd want to only include this under fission, but I >> admittedly don't fully understand it anyway. >> > > So we're not particularly using it correctly at the moment (given that > it was relatively undocumented and I had word of mouth when > implementing it), but the basic idea is that relocations to the range > sections will be based off of a single relocation rather than have a > bunch of them.Right - use one reloc and then offsets for the rest I suppose. Seems like a reasonable feature but one we're basically not using at all (just not "not using correctly"). As usual, I'd be inclined to rip it out until it's used (until we actually emit the non-reloc, offset-based AT_range values), but not too fussed.> It's not necessarily fission only, but it hasn't been standardized yet > and is a bit of an experiment and still undergoing revision. I can > disable it/command line if you think that's appropriate as well.Doesn't seem terribly necessary - was more just curious about the inconsistency & whether there was some logic to that I was missing or an oversight we should fix.