On 8/26/21 3:38 PM, Simon Marchi wrote:
> On 2021-08-26 7:56 a.m., Tom de Vries via Gdb-patches wrote:
>> Hi,
>>
>> We can use current dwarf assembly infrastructure to declare a label that marks
>> the start of the CU header:
>> ...
>>   declare_labels header_start_cu_a
>>   _section ".debug_info"
>>   header_start_cu_a : cu {} {
>>   }
>>   _section ".debug_info"
>>   header_start_cu_b : cu {} {
>>   }
>> ...
>> on the condition that we switch to the .debug_info section before, which makes
>> this style of use fragile.
>>
>> Another way to achieve the same is to use the label as generated by the cu
>> proc itself:
>> ...
>>   variable _cu_label
>>   cu {} {
>>   }
>>   set header_start_cu_a $_cu_label
>>   cu {} {
>>   }
>>   set header_start_cu_b $_cu_label
>> ...
>> but again that seems fragile given that adding a new CU inbetween will
>> silently result in the wrong value for the label.
> 
> And this is done by poking in the internals of the framework, not good.
> 
>> Add a label option to proc cu such that we can simply do:
>> ...
>>   declare_labels header_start_cu_a
>>   cu { label header_start_cu_a } {
>>   }
>>   cu { label header_start_cu_b } {
>>   }
> 
> That looks like the right way to do it.  But can we make it so the
> caller doesn't need to use declare_labels?  For example, with rnglists'
> -post-header-label switch, it's not needed, so I presume it would be
> possible here.

Done.

I looked at -post-header-label, but that puts the burden on the caller
to come up with a unique name.  That doesn't work well with proc
dummy_cu being defined like this:
...
    proc dummy_cu {} {
        # Generate a CU with default options and empty body.

        cu {label dummy_cu} {
        }

        # Generate an .debug_aranges entry for the dummy CU.

        aranges {} dummy_cu {
        }
    }
...
and then being called twice.

Instead, I opted to reuse _cu_label, but rather than poking it's now
exported by the proc.

WDYT?

Thanks,
- Tom