On Thu, 2024-10-17 at 12:30 +0000, John DelSignore wrote: > > Hi, > > I think the best way to encode the information depends on details of > the processor architecture.
Hi John, Thanks for the reply, and it's interesting to hear about that Itanium case! The scheme that you describe below seems well-suited for such architectures with fixed-sized, aligned bundles. Unfortunately, for this particular architecture the distance between consecutive bundles is not constant, so it is not possible to tell where bundles start or end just by looking at the address. > The IA-64 (Intel Itanium architecture) had a VLIW instruction > encoding with a 128-bit instruction bundle consisting of three 41-bit > instruction slots per bundle plus a 5-bit template indicating the > type of instruction in each slot. Memory was 8-bit byte addressable, > and an instruction address was encoded as a 128-bit (16-byte) aligned > bundle address plus a bundle index. So, if the bundle was at address > 0x56780, the second instruction in the bundle was encoded as 0x56781. > It's been a long time since I have worked on an IA-64 systems, but I > believe this convention was used by both the processor and in the > DWARF. Of course our debugger needed to be modified to handle these > conventions, but it didn't require anything special the DWARF because > the bundle address+index convention carried through to all DWARF > addresses. A benefit with use of op_index for this architecture is that consumers can easily retrieve all locations that belong to a bundle by traversing the line table rows until the address changes. To achieve the same for this architecture when using the bundle-start-address + offset scheme, it would then seem like we would need to either somehow encode where bundles start or end in the debug information (using some sort of extension?), or let the consumer (or its user) figure out where bundle boundaries are by looking at disassembled binary output or some side table containing that information. If we wish to keep modeling with op_index, and it is not possible to represent multiple call chains for the same address in the "Subroutine and Entry Point Entries" debug information, I guess we need to either find a common shared scope for all the instructions in a bundle, or use some heuristic that picks the "most relevant" call chain from the different instructions in the bundle. It would be interesting to understand how other producers using op_index for a VLIW architecture or producers emitting the Location View Numbering information for a non-VLIW architecture have handled that. > Cheers, John D. Best regards, David -- Dwarf-discuss mailing list Dwarf-discuss@lists.dwarfstd.org https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
