[Dwarf-discuss] PROPOSAL: add support for bundled instructions (e.g., Itanium)

[Cary Coutant]

[Resubmitted with the right mailing address. Sorry!]

I submitted this idea for discussion last year, and got some positive  
feedback, but never followed through. Here's a formal proposal for  
the next DWARF revision.

Chris had these comments on July 14, 2006:

> Shouldn't the new header fields go at the end
> of the header so that old code might still work?
> Of course, you would also want to update the version
> number for that dwarf section.

I'd prefer to see them immediately following the  
minimum_instruction_length field. Moving them to the end means that  
they'd end up following three variable-length fields: the array of  
standard opcode lengths, and the two lists of include directory names  
and file names (with the extra null byte at the end of each list).  
That's just begging for trouble. Any old code trying to read a line  
number table that uses this new convention just isn't going to work  
anyway. Any old code trying to read a new line number table that  
doesn't use this convention won't see any difference, and will  
continue to work.

> Also, you could leave the minimum instruction length
> set to something normal (like 1 or 16) and use a non-zero
> value in the two new fields to indicate the new
> style of information.

Again, I don't think that's going to help old code -- it would just  
make it *think* it's working, while producing nonsense instruction  
addresses.

-cary


Background

On the Itanium architecture, three instructions are packed into one  
16-byte "bundle". Only the bundle itself has a real (16-byte aligned)  
address, leaving the compiler and debugger to agree on a convention  
for how to represent the addresses of the instructions inside the  
bundle. On HP-UX, we use the bundle address plus 0, 4, and 8 to  
represent these; Linux has chosen the bundle address plus 0, 1, and  
2. In the line number program, we set minimum_instruction_length to  
4, and we then have to use increments of 1, 1, 2, 1, 1, 2, ....  
Worse, Linux chose to set minimum_instruction_length to 1, and uses  
increments of 1, 1, 14, 1, 1, 14, .... Ideally, I'd like to set  
minimum_instruction_length to 16/3, so we can just use uniform  
increments of 1.

Proposal

I propose to extend the definition of the minimum_instruction_length  
field of the line number program header, in Section 6.2.4, as follows:

"If minimum_instruction_length is zero, it is immediately followed by  
two additional ubytes -- bundle_length and  
instruction_slots_per_bundle. For architectures with instruction  
bundles, the address register has two components: a bundle address  
and a slot number. Line number program opcodes that alter the address  
register first compute the new bundle address as (bundle_adress +  
bundle_length * ((slot_number + operand) div  
instruction_slots_per_bundle)), then compute the new slot number as  
((slot_number + operand) rem instruction_slots_per_bundle), where div  
and rem are defined such that (a div b) is an integer and a = (a div  
b) * b + (a rem b) and 0 <= (a rem b) < b."

For Itanium, we would set the minimum_instruction_length field to 0,  
followed by the bundle_length and instruction_slots_per_bundle fields  
of 16 and 3, respectively. (We consider all bundles to have exactly 3  
slots, even for those bundle type where one instruction spans two  
slots.)

Because this change has the potential to break existing consumers,  
the version number in the line number program header, specified in  
Section 7.21, should be changed to 4, although producers who do not  
set minimum_instruction_length to zero can (and should?) continue to  
generate version 3.

-cary