On Wed, Jun 16, 2010 at 05:06:29PM -0700, Roland McGrath wrote:
> Are there any plans to make GCC and/or GAS emit the version 4 variants of
> the .debug_line and/or .debug_frame formats?
>
> The .debug_line version 4 format only adds the "maximum operations per
> instruction" header field and associated logic, which is only meaningful
> for VLIW machines (i.e. ia64--are there others?). The old format is
> specified such that it's always safe to use the new line-number program
> operations without changing the header version field, so there is no real
> reason to emit the new header format unless using the VLIW support. But it
> seems consistent with the rest of the behavior of -gdwarf-4 to emit the v4
> format with that option. I'd like to know when or if to expect ever to see
> this format.
>
> Similarly, the .debug_frame version 4 format only adds the address_size and
> segment_size header fields. I don't know if there are any GCC/GAS target
> configurations that support segmented addresses for code so as to need
> segment_size, or any that support using an address size other than that
> implied by the ELF file class (or another container format's explicit or
> implicit address size, or the architecture's implicit address size) so as
> to need address_size. But the same logic and questions apply as for
> .debug_line even so. OTOH, e.g. x86-64 -mcmodel=small could use
> address_size 4 and save some space in the .debug_frame output.
I'd say we should switch to version 4 only when we need the new fields
(i.e. if ia64 or other VLIW starts using the new VLIW .debug_line features,
let it use version 4, but for other targets 3 would be good enough).
Similarly for .debug_frame.
Jakub
