llvm dev - Dec 2013 - [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

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

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.