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

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

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.

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.

Yep. And sure, that seems reasonable.

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.

Yep. Pretty much got left behind in the ever evolving standardization thing.

-eric