Re: PROPOSAL(2): New FORMs DW_AT_linep, locp, macp (64 bit file size safety)

[Michael Eager <eager at eagercon dot com>]

James Cownie wrote:
> 
> >  We have four sections that contain data that
> > DIEs wind up pointing to via various attributes:
> >
> >       Section         Attribute(s)    FORM classes
> >
> >       .debug_line     stmt_list       data{4,8}
> >       .debug_loc      location, etc.  data{4,8}
> >       .debug_macinfo  macro_info      data{4,8}
> >       .debug_str      name, etc.      strp
> 
> What about the .debug_pub* sections ?
> 
> The spec there also appears to be _very_ weak, it just says
> 
>   Each set begins with a header containing four values: the total length
>   of the entries for that set, not including the length field itself, a
>   version number, the offset from the beginning of the .debug_info
>   section of the compilation unit entry referenced by the set and the
>   size in bytes of the contents of the .debug_info section generated to
>   represent that compilation unit. This header is followed by a variable
>   number of offset/name pairs. Each pair consists of the offset from the
>   beginning of the compilation unit entry corresponding to the current
>   set to the debugging information entry for the given object, followed
>   by a null-terminated character string representing the name of the
>   object as given by the DW_AT_name attribute of the referenced
>   debugging entry. Each set of names is terminated by zero.
> 
> which doesn't specify the _size_ of the "offset" or length
> fields at all.

I believe that there is a blanket statement in the spec that all values
are the natural word length of the target machine.

> Clearly we need to specify the sizes of these fields, and how they
> interact with 64 bit file/section offsets elsewhere.
> 
> It seems that we may need to upgrade the header version and add an
> additional field to the header to specify how large the offsets are to
> be ?

Which would break compatibility with prior versions of Dwarf.

> Even this appears to have a problem, since existing code will be
> reading the "total length of the entries for that set" as a 32 bit
> quantity and we may need that to be a 64 bit quantity. However the
> length of that field affects where one looks for the version number
> :-(

Let's not try to address two independent issues at the same time.  There
is a proposal about 64-bit dwarf.  Your comments are appropriate with 
regard to that proposal.

-- 
Michael Eager	 Eager Consulting     eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077