Re: Support AArch64 MTE memory tag dumps in core files

[Luis Machado <luis.machado@arm.com>]

Hi Alan,

On 4/1/22 02:34, Alan Modra wrote:
> On Thu, Mar 31, 2022 at 03:04:57PM +0100, Luis Machado via Binutils wrote:
>> diff --git a/bfd/section.c b/bfd/section.c
>> index 9a1071454f5..e8c7caf9dd4 100644
>> --- a/bfd/section.c
>> +++ b/bfd/section.c
>> @@ -412,6 +412,9 @@ CODE_FRAGMENT
>>   .  {* Nonzero if this section uses RELA relocations, rather than REL.  *}
>>   .  unsigned int use_rela_p:1;
>>   .
>> +.  {* Nonzero if this section contains memory tag data.  Default is 0.  *}
>> +.  unsigned int has_memory_tags : 1;
>> +.
>>   .  {* Bits used by various backends.  The generic code doesn't touch
>>   .     these fields.  *}
>>   .
>> @@ -455,6 +458,11 @@ CODE_FRAGMENT
>>   .  {* The compressed size of the section in octets.  *}
>>   .  bfd_size_type compressed_size;
>>   .
>> +.  {* If HAS_MEMORY_TAGS is true, MEMORY_TAGS_RANGE_SIZE is the original memory
>> +.     range size, in octets, of the memory that contained the tags stored in this
>> +.     section.  SIZE is the size of the packed tags from that memory range.  *}
>> +.  bfd_size_type memory_tags_range_size;
>> +.
>>   .  {* Relaxation table. *}
>>   .  struct relax_table *relax;
>>   .
> 
> Really, you shouldn't be adding fields used by just one target to
> struct bfd_section.  The linker might be dealing with hundreds of
> thousands of sections.  If every target added fields because it was
> convenient to do it that way, we'd end up with quite a non-trivial
> memory cost for all targets.  Instead, you should look at adding the
> new field to _aarch64_elf_section_data.

That's a valid point. I was considering potential future use of memory 
tags by other architectures. Right now AArch64 and SPARC use it, but I 
understand the memory restrictions. I'm still finding my way through 
this code.

Let me rework this and shift these fields to a more arch-specific 
location. Thanks for the feedback!

> 
> Yes, I know target specific fields have sneaked past review in the
> past, eg. relax and relax_count are microblaze only.  I might even get
> around to fixing those one day.
>