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

[Zoran Zaric via Gdb-patches <gdb-patches@sourceware.org>]

>>>
>>> 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

This is not exactly true, you can always define a CFI that doesn't need 
any assembly code considering that register values can be set from the 
the test itself or if only CFI register rules that target a memory 
locations are used.

With the new extensions that I've contributed (and are currently under 
the review) the register rules mechanism now supports any location 
description to be part of the DWARF expression. With this extension, you 
can imagine that a very complex DWARF expression that doesn't use any 
potentially ABI sensitive resource, can still be written and tested in 
the same way as any variable location.

Another option is to only hand write a CFI table for the top level 
function (frame 0) and design a way to merge the original CFI generated 
by the compiler for other functions with the hand written one.

Also, with a potential new operation DW_OP_LLVM_call_frame_entry_reg 
described at length here:

https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html

This would allow us to test any CFI expression of the frame we are 
currently stopped in.

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

But, isn't this the case for any part of the DWARF assembler functionality?

Writing any complex DWARF expression fast in any assembly is hard and 
time consuming.

I agree that adding a CFI support requires more thought and effort and 
better understanding about how the CFI works and what is safe to use 
from a test writer perspective, but I can definitely see the benefit of 
adding that support in the future.

Zoran