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

[David Weatherford <david dot weatherford at sun 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 ?

There are no pointers from .debug_info to .debug_pubnames.  Besides,
Section 7.19 already addresses the issue.  In the latest (April 5)
draft, it says that if the 4-byte length is 0xffffffff, then it's
followed by an 8-byte unsigned integer that is the actual length,
and the 4-byte offset is 8 bytes instead, etc.

I don't think there's any more to be done for .debug_pubnames,
or .debug_aranges.

> 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.
> 
> Clearly we need to specify the sizes of these fields, and how they
> interact with 64 bit file/section offsets elsewhere.

The section you quote, 6.1.1, is just the semantic description.  See
Section 7.19 for the data layout.

In general, everything in sections 1-6 avoids talking about the
data layout.  Section 7 has the details.

> 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 ?
> 
> 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
> :-(
> 
> -- Jim
> 
> James Cownie    <jcownie@etnus.com>
> Etnus, Inc.     +44 117 9071438
> http://www.etnus.com

-- 
Dave Weatherford                Forte Tools
David.Weatherford@Sun.COM       Sun Microsystems, Inc.