Support AArch64 MTE memory tag dumps in core files
Luis Machado
luis.machado@arm.com
Fri Apr 1 08:21:18 GMT 2022
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.
>
More information about the Binutils
mailing list