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:
Address Line Column File ISA Discriminator OpIndex Flags
-------------- ------ ------ ------ --- ------------- ------- --------
0x000000000000 2 2 2 0 0 0 is_stmt
0x000000000000 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://dwarfstd.org/issues/170427.1.html
--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss
