Hi,
I think the best way to encode the information depends on details of the
processor architecture. 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.
Cheers, John D.
-Original Message-
From: Dwarf-discuss
On Behalf
Of David Stenberg via Dwarf-discuss
Sent: Thursday, October 17, 2024 7:24 AM
To: dwarf-discuss@lists.dwarfstd.org
Subject: [Dwarf-discuss] Multiple inlined subroutines for a VLIW instruction
bundle?
Hi!
Is it possible to encode different backtrace information, including inlining,
for two different instructions in a VLIW bundle?
I'll probably use inprecise and non-standard wording below. Sorry if that is
the case.
Assume that the following C program:
foo.h:
static inline void foo_inl_inner() {
__builtin_insn1(); // line 2
}
static inline void foo_inl_outer() {
foo_inl_inner(); // line 6
}
bar.h:
static inline void bar_inl() {
__builtin_insn2(); // line 10
}
main.c:
int main() {
foo_inl_outer(); // line 2
bar_inl(); // line 3
}
where __builtin_#X corresponds to a hardware instruction #X, is compiled for a
VLIW architecture. We may then end up with an VLIW instruction bundle where
insn1 and insn2 are bundled together:
{
insn1 # foo.h:2
insn2 # bar.h:10
}
We are able to describe the locations for the two operations in the instruction
bundle by using the op_index register in the line number program, for example
something like this:
AddressLine Column File ISA Discriminator OpIndex Flags
-- -- -- -- --- - ---
0x 2 2 2 0 0 0 is_stmt
0x 10 2 3 0 0 1 is_stmt
[...]
For our proprietary VLIW architecture we have debugging and profiling tools
that are able to indicate which operations in a VLIW bundle that are of
interest, and we would like to query the line information about those specific
operations.
If we do not care about inline subroutines, the use of the op_index register in
the line number program is sufficient for us to query line and file for the
different operations, for example:
$ debug-tool --no-inlines [PC=...] [op-index=0]
foo.h:2
$ debug-tool --no-inlines [PC=...] [op-index=0]
bar.h:10
However, we would also want to be able to query information about the two call
chains, showing the inlined subroutines, making it easier for our users to
understand from where the operations originate from. For
example:
$ debug-tool --inlines [PC=...] [op-index=0]
foo_inl_inner[foo.h:2]
inlined @ foo_inl_outer[foo.h:6]
inlined @ main[main.c:2]
$ debug-tool --inlines [PC=...] [op-index=1]
bar_inl[bar.h:10]
inlined @ main[main.c:3]
If I understand correctly, we would somehow need to encode that information in
the "Subroutine and Entry Point Entries" debug information.
Would a DWARF producer be allowed to emit DW_TAG_subprogram and concrete
DW_TAG_inlined_subroutines entries that describe those two different call
chains for the addresses of that single instruction bundle?
For example, something like this:
DW_TAG_subprogram
DW_AT_name "main"
DW_AT_low_pc 0x0
DW_AT_high_pc 0x2
DW_TAG_inlined_subroutine
DW_AT_abstract_origin "foo_inl_outer"
DW_AT_low_pc 0x0
DW_AT_high_pc 0x2
DW_TAG_inlined_subroutine
DW_AT_abstract_origin "foo_inl_inner"
DW_AT_low_pc 0x0
DW_AT_high_pc 0x2
DW_TAG_inlined_subroutine
DW_AT_abstract_origin "bar_inl"
DW_AT_low_pc 0x0
DW_AT_high_pc 0x2
If that is the case, I do not find anything in the standard that would help us
connect the op_index values to those inlined subroutines. Is that correct?
Or are there any other way that we could or should model information about
inline subroutines for such VLIW instruction bundles?
The above questions concern how to handle VLIW debug information with DWARFv5,
but I think they may be relevant for non-VLIW architectures with the Location
View Numbering information suggested for DWARFv6 [1], as you may encounter
similar situations when merging instructions coming from different inlined
subroutines.
Best regards,
David
[1] https://dwar
