[Dwarf-Discuss] DWARF for DSP like processors with multiple memories

[Anthony Berent]

> -----Original Message-----
> From: David Anderson [mailto:davea42 at earthlink.net] 
> Sent: 24 November 2008 18:01
> To: Anthony Berent; dwarf-discuss at lists.dwarfstd.org
> Subject: Re: [Dwarf-Discuss] DWARF for DSP like processors 
> with multiple memories
> 
> Anthony Berent wrote:
> > Hi,
> >  
> > I am looking for some advice on the correct use of DWARF for 
> > describing code running on an ARM Data Engine. ARM Data Engines are 
> > DSPs with multiple memories (not just data and instruction, but 
> > multiple data memories), each independently addressed. The C source 
> > code used to program the Data Engines uses pragmas to 
> assign variables 
> > to particular memories, and to qualify pointers with the targeted 
> > memory. The addresses used within the processors never include an 
> > explicit memory identifier, instead there are different 
> instructions to access each memory.
> >  
> > At the moment our DWARF description uses segment attributes 
> > (DW_AT_SEGMENT) to describe the allocation of variables to 
> memories, 
> > but we are not sure if this is a correct use of DWARF. In 
> particular:
> >
> > 1.	Is this a reasonable use of DW_AT_segment, which was, I believe,
> > originally created for processors with segmented memory of the sort 
> > implemented in small-mode x86?
> >   
> 
> IMO it is the right thing to do.   DW_AT_segment was intended
> for all situations with a non-flat memory addressing model.
> I don't know if anyone has used it before (and if so they do 
> not seem to have indicated to the committee how well it all worked).
> 
> > 2.	Is anybody currently using DW_AT_segment in a similar way, or
> > solving a similar problem in a different way? If so, for which 
> > architectures?
> >
> > 3.	How should we describe which memory is targeted by pointers? Is
> > using the DW_AT_address_class the right way to do this?
> >   
> 
> DW_AT_address class is (as you already know) intended to 
> indicate how to interpret the bits of an address.  If the 
> address contains a segment identifier in it, this would be a 
> way to describe such.
> But that is not your situation it if I understand your
> description.   DW_AT_segment seems like your best bet, but
> of course take my opinion very lightly :-)

The problem I see with this is that we need to record two things for a
pointer variable; the memory containing the variable, and the memory it
points to. DW_AT_segment is already in use for the describing the memory
containing the variable, so we can't use this for describing the memory
pointed to. A possibly theoretically correct solution would be to include
this in the pointer type description, rather than the variable description,
but I can't see a way of doing this in DWARF (DW_AT_segment isn't legal in a
type description).

> > 4.	Is there any way of describing in DWARF which memories 
> contain the
> > stack? I can't see any way of including segment information 
> in DWARF 3 
> > call frames, and, if I am reading it correctly the DWARF 4 draft I 
> > have seen this only supports segment information in the PC 
> value in call frames.
> >   
> 
> Unclear to me what the previous sentence means (after the 
> second comma).

Sorry I was unclear; the DWARF 4 draft allows a segment selector in
DW_CFA_set_loc, but, if I am reading it correctly, this is a segment
selector for the referenced target address, not a segment selector for the
call frame itself. As far as I can see there is no way of specifying a
segment (or segment calculation) for the call frame or for any of the
registers in the call frame.

> I don't have an answer to the question above.
> > 	*	I say memories (plural) because some ARM Data 
> Engines only
> > allow certain registers to be saved in particular memories, so we 
> > sometimes need multiple stacks.
> >
> >   
> Hmm.  No idea what to do about that, offhand.
> 
> > Many thanks for any advice anybody can give.
> >   
> 
> Do let  us know (via dwarf-discuss) how it all goes.
> 
> Regards,
> David Anderson.
> 

Thanks for your help, and I will let you know how it goes

- Anthony