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 
<dwarf-discuss-bounces~jdelsignore=perforce....@lists.dwarfstd.org> 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:

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


CAUTION: This email originated from outside of the organization. Do not click 
on links or open attachments unless you recognize the sender and know the 
content is safe.

This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Reply via email to