[llvm-dev] DWARF .debug_aranges data objects and address spaces

[Pavel Labath via llvm-dev]

On 17/03/2020 14:46, Robinson, Paul wrote:
> 
> 
>> -----Original Message-----
>> From: Pavel Labath <pavel at labath.sk>
>> Sent: Tuesday, March 17, 2020 3:02 AM
>> To: David Blaikie <dblaikie at gmail.com>; Robinson, Paul
>> <paul.robinson at sony.com>
>> Cc: llvm-dev at lists.llvm.org
>> Subject: Re: [llvm-dev] DWARF .debug_aranges data objects and address
>> spaces
>>
>> On 16/03/2020 18:20, David Blaikie via llvm-dev wrote:
>>> On Mon, Mar 16, 2020 at 9:31 AM Robinson, Paul <paul.robinson at sony.com
>>> <mailto:paul.robinson at sony.com>> wrote:
>>>
>>>     With AVR being affected, upstreaming a patch to put segment
>>>     selectors into .debug_aranges becomes completely reasonable.  There
>>>     would likely want to be a target hook somewhere to return a value
>>>     saying what size to use, with the default implementation returning
>> zero.
>>>
>>>
>>> *nod* something along those lines
>>>
>>
>> Does that mean putting the selector *only* into debug_aranges (and not
>> debug_line, debug_frame, etc.)?
> 
> That was my thought, yes.  It's the only section where there is no other
> context to determine whether a raw address is for code or for data.
> 
>>
>> Even though they are not really needed if the target only ever has one
>> code address space, it seems somewhat odd to have different values for
>> segment_selector_size in different sections.
>>
>> In the DWARF spec these are described as "... containing the size in
>> bytes of a segment selector on the _target system_". I would interpret
>> the "target system" portion of that as meaning that the segment selector
>> size is a property of a target, and hence, it should be consistent
>> across all relevant sections.
> 
> For a target with actual segments (like 80x86) the selector would always
> have to be present.
> 
> For a Harvard target there is no explicit selector in the machine code, 
> and a strict reading of the DWARF spec would require the segement selector
> size to be zero in all cases; but that leaves us where we are today, with
> .debug_aranges being impossible to interpret correctly.
> 
> IMO, having a segment selector in .debug_aranges and nowhere else, for a
> Harvard architecture, falls within the "permissive" aspect of DWARF.  It
> solves an actual problem using what is IMO a reasonable interpretation of
> the existing DWARF feature set.  If the AVR (+other Harvard-like) targets
> prefer, I wouldn't stop them from adding a segment selector to all DWARF
> sections, but it seems like a waste of space in other sections.
> 
> I'd be happy to propose a DWARF wiki item or even a non-normative bit of
> text in the spec, to codify this.  It would affect consumers that target
> a Harvard architecture, but they have to contend with this somehow in any
> case.
> --paulr

Thanks for sharing your thoughts Paul. I agree that putting the unused
segment selectors everywhere is silly, but I also think that different
selector sizes in different sections could be confusing/surprising -- I
find it about equally surprising as using different values of
address_size in different sections. That too could potentially be useful
(is e.g. the code address space is significantly smaller than the data
address space) -- but it would definitely raise some eyebrows.

I think that some bit of text to make this more "official" be useful.

pl