Re: [PATCH 10/13] gdb/testsuite: add .debug_loclists tests

[Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>]

On 2021-01-28 11:52 a.m., Zoran Zaric wrote:>> From: Simon Marchi <simon.marchi@efficios.com>
>>
>> Add tests for the various issues fixed in the previous patches.
>>
>> Add a new "loclists" procedure to the DWARF assembler, to allow
>> generating .debug_loclists sections.
>>
> 
> Thank you for this contribution.
> 
> Having a loclists support in DWARF assembler gives us so considerable testing flexibility and decouples the gdb testing even more from what compiler is expected to generate.
> 
> The only thing missing now (at least in my mind) is the CFI support but that is a big project for the future.

Given that:

 - the actual assembler (GNU as or other) already has support for
   specifying and generating CFI, and
 - a test case that wants to use specific CFI would contain some
   assembly code already, to control exactly which instructions are
   generated

I don't think our assembler needs to know how to generate CFI, you'd
just write it in platform-specific assembly.

>> +
>> +    proc loclists { args } {
>> +       variable _debug_loclists_addr_size
>> +       variable _debug_loclists_offset_size
>> +       variable _debug_loclists_is_64_dwarf
>> +
>> +       parse_args {{"is-64" "false"}}
>> +
>> +       if { [llength $args] != 1 } {
>> +           error "loclists proc expects one positional argument (body)"
>> +       }
>> +
>> +       lassign $args body
>> +
>> +       if [is_64_target] {
>> +           set _debug_loclists_addr_size 8
>> +       } else {
>> +           set _debug_loclists_addr_size 4
>> +       }
>> +
>> +       if { ${is-64} } {
>> +           set _debug_loclists_offset_size 8
>> +           set _debug_loclists_is_64_dwarf true
>> +       } else {
>> +           set _debug_loclists_offset_size 4
>> +           set _debug_loclists_is_64_dwarf false
>> +       }
>> +
>> +       _section ".debug_loclists"
>> +
>> +       # Count of tables in the section.
>> +       variable _debug_loclists_table_count 0
>> +
>> +       # Compute the label name for list at index LIST_IDX, for the current
>> +       # table.
>> +
>> +       proc _compute_list_label { list_idx } {
>> +           variable _debug_loclists_table_count
>> +
>> +           return ".Lloclists_table_${_debug_loclists_table_count}_list_${list_idx}"
>> +       }
>> +
>> +       # Generate one table (header + offset array + location lists).
>> +       #
>> +       # Accepts one position argument, BODY.  BODY may call the LIST_
>> +       # procedure to generate loclists.
>> +       #
>> +       # The -post-header-label option can be used to define a label just after the
>> +       # header of the table.  This is the label that a DW_AT_loclists_base
>> +       # attribute will usually refer to.
>> +
>> +       proc table { args } {
>> +           variable _debug_loclists_table_count
>> +           variable _debug_loclists_addr_size
>> +           variable _debug_loclists_offset_size
>> +           variable _debug_loclists_is_64_dwarf
>> +
>> +           parse_args {{post-header-label ""}}
>> +
>> +           if { [llength $args] != 1 } {
>> +               error "table proc expects one positional argument (body)"
>> +           }
>> +
>> +           lassign $args body
>> +
>> +           # Generate one location list.
>> +           #
>> +           # BODY may call the various procs defined below to generate list
>> +           # entries.  They correspond to the location list entry kinds
>> +           # described in section 2.6.2 of the DWARF 5 spec.
>> +           #
>> +           # To define a label pointing to the beginning of the list, use
>> +           # the conventional way of declaring and defining labels:
>> +           #
>> +           #   declare_labels the_list
>> +           #
>> +           #   the_list: list_ {
>> +           #     ...
>> +           #   }
>> +
>> +           proc list_ { body } {
>> +               variable _debug_loclists_list_count
>> +
> 
> I guess that the table and list procedures from loclist and ranglist support couldn't be commonized in some way?
> 
> They do seem considerably different.

Yeah, they are similar (once you understand one, it's very easy to
understand the other).  But they are not identical.  So given that we
have only two kinds, I think it would just make it more complex for
nothing to try to factor out the common parts.  If we had 20 kinds, then
maybe it would be a different story :).

Simon