https://sourceware.org/bugzilla/show_bug.cgi?id=34305
Bug ID: 34305
Summary: [avr] Support .gnu_attribute 4 (Tag_GNU_AVR_VTABLE_AS)
Product: binutils
Version: 2.45
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Created attachment 16789
--> https://sourceware.org/bugzilla/attachment.cgi?id=16789&action=edit
Proposed patch
The expected, upcoming support for ISO/IEC TR 18037 "Embedded C" named address
spaces in G++ would allow to put C++ virtual tables into such address spaces,
see https://gcc.gnu.org/PR69549.
Currently, vtables are in the generic address space, which wastes RAM on cores
that locate .rodata in RAM.
Any change of vtables' address space is an ABI change, and therefore it would
be nice to have a feature that checks whether all object files linked into an
app are using the same vtable AS.
This PR is a proposal to introduce .gnu_attribute 4 (Tag_GNU_AVR_VTABLE_AS).
The compiler would set this attribute according to the selected address space,
and the linker would complain when an attempt is being made to link
incompatible object files together.
Here is a proposed patch:
https://sourceware.org/pipermail/binutils/2026-June/149625.html that recognized
the following values for Tag_GNU_AVR_VTABLE_AS:
0 (Val_GNU_AVR_VTABLE_NONE) for files that neither define nor access
vtables.
1 (Val_GNU_AVR_VTABLE_RAM) use the generic address space.
2 (Val_GNU_AVR_VTABLE_FLASH) use the 16-bit address space __flash.
3 (Val_GNU_AVR_VTABLE_FLASH1) use the 16-bit address space __flash1.
4 (Val_GNU_AVR_VTABLE_FLASH2) use the 16-bit address space __flash2.
5 (Val_GNU_AVR_VTABLE_FLASH3) use the 16-bit address space __flash3.
6 (Val_GNU_AVR_VTABLE_FLASH4) use the 16-bit address space __flash4.
7 (Val_GNU_AVR_VTABLE_FLASH5) use the 16-bit address space __flash5.
8 (Val_GNU_AVR_VTABLE_FLASHX) use the 24-bit address space __flashx.
--
You are receiving this mail because:
You are on the CC list for the bug.
